[Coco] 16550 wasRe: RS232 paks

[Mark Marlette]

George,

Do not forget that the chip does work. It just doesn't work in all conditions.

If it didn't work they wouldn't sell it.

In your application is obviously is working for you. I have stated the conditions, SockMaster did as well. It will fall flat on it's face.

'For a Few Dollars More', you can have the real deal. Problem is that the 16550 will not support the legacy term programs for the CoCo, there are all kinds of issues that we deal with when adding technology to an old computer. It is way more work to implement but that is why it is on the SB. Can't have lost data, ever.

Clint Eastwood fans will get my movie title above.... :)

Regards,

Mark


----- Original Message -----
From: "George Ramsower" <georgeramsower at gmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, March 4, 2009 7:19:25 PM GMT -06:00 US/Canada Central
Subject: Re: [Coco] 16550 wasRe:  RS232 paks

hmm.
 I think I'll have to find some time and see how I built that 3 port com 
board. It works goodly. I'm wondering if I made those changes to the 
intended design.
 All I know now is that it works. I ran two modems on two different 
telephone exchanges and it eliminated long distance charges from one to the 
other. I was lucky enough to be in the middle and didn't have to pay between 
them.
 This was the old way to do BBS systems to avoid long distance charges. I 
didn't join a network and therefore, I was not a hub.
 "Hub" was that what it was called? Dammit, I can't remember.

George

----- Original Message ----- 
From: "Mark Marlette"
> George,
>
> Google a bit and you will see, it is a wonderful tool.
>
> Maybe you will believe our own SockMaster on the subject.......
>
> http://www.axess.com/twilight/sock/cocofile/rs232mod.txt
>
> This is an extraction from his article from :
>
>   Now for what IS in the diagram:  The other problem with putting a 
> high-speed
> modem on my BBS is a little less important,  but fixing it makes 
> everything
> much easier.  With this modification the CPU gets less bogged down, the 
> RS-232
> driver becomes easier to write, and the BBS *never* misses any incoming 
> data.
> Normally, the 6551 simply has no way of telling my modem when it's data 
> buffer
> is full.  If someone called my BBS at a high baud rate and tried uploading 
> a
> text file, my driver simply didn't read the data fast enough to get it all
> without missing bytes. Every time the disk drive went on, the CPU halts 
> and the
> 6551 misses more data.  In order not to miss data, the RS-232 driver would 
> have
> to immediately read data from the 6551 every time a byte came in.  The
> solution?  I made a little circuit that sits on top of the 6551 chip (a 
> 74ls32
> and 74ls00) that generates a new RTS control signal.  Since modern modems 
> have
> a data buffer, it would be really neat to unload a lot of work from the 
> CoCo
> and leave it for the modem to do.  This hardware circuit simply creates a 
> new
> RTS line for the 6551.  Every time the 6551 receives data, the circuit 
> raises
> the RTS line (which tells the modem to stop sending to the CoCo) until 
> that
> data is read by the software.  If the driver reads the data at the full
> incoming speed, there is no slowdown in throughput.  If the driver goes on 
> a
> break, or the disk drive comes into use... whatever, the modem is told not 
> to
> send any more data to the 6551 until the 6551 is ready to recieve it!
> Effectively, the circuit disallows the 6551 from missing any data.  It 
> also
> places the job of buffering incoming data on the modem, and not the CoCo.
> The CoCo doesn't have to keep reading the 6551 every time a byte comes in,
> since it won't lose the data if it lets it wait.  Now it can read the data
> when it actually wants it.  This speeds up my BBS quite a bit,  I only 
> read
> from  the 6551 when the BBS wants input from the user.  If the user 
> transmits
> stuff while the BBS is calculating, loading, thinking, etc... the modem 
> will
> buffer it for me.
>
>
> Regards,
>
> Mark
> Cloud-9
> ----- Original Message -----
> From: "George Ramsower"
> ----- Original Message ----- 
> From: "Roger Taylor"
>> At 09:40 AM 3/4/2009, you wrote:
>>>Willard,
>>>
>>>The NitrOS-9/Driver is already written for a 16550 device. I have had a
>>>homebrew card running for almost 10yrs based upon that chipset.
>>>
>>>Yes, it would break all the old term programs. A caveat of adding new
>>>technology to an old machine. Not a problem in NitrOS-9 as the driver/dd
>>>is not part of the actual program, when properly written.
>>>
>>>The SuperBoard has a multi-function chip on it that has the 16550 in it.
>>>Anyone that has done high speed serial testing in a system will design it
>>>with hardware handshaking. It is no secret that the ACIA(6551) has issues
>>>with this, plus almost no buffer space. Not a good choice for new 
>>>designs,
>>>IMHO. 16xxx series offers GREAT buffers, programmable interrupt 
>>>thresholds
>>>etc..... I guess that is why they are so common, oh they work too! :)
>>>
>>>Regards,
>>>
>>>Mark
>>>Cloud-9
>>
>>
>> Mark,
>>
>> Exactly what problems have you yourself had with the 6551 so that I may
>> try to offer a software solution?  I'm not claiming to have all the
>> answers, but I've done a serious amount of 6551 coding in the past, and I
>> can assure you that the chip itself is not always the problem.  The
>> programmer is 90% of the problem.  The OS is 90% of the problem.  If
>> there's some little bug or dislike about a certain chip, I guarantee that
>> there's the same number or more in the 16550.  I've read about that chip
>> and based on how many variants are floating around, how can anyone ever
>> agree on a right way to code the routines?  It appears to be a mess, no
>> less than what you claim about the 6551.  I'm not saying any certain chip
>> is BETTER than the other.. I'm saying that TOO many programmers and
>> nonprogrammers have clashed about these chips and in the end, they're all
>> still being used today.  You can always tell when the programmer took
>> shortcuts or just didn't know what he was doing.
>>
>> When you say the 6551 is not a wise choice for any new designs, your
>> intent is clear but the statement is not true.  Someone who's put out a
>> new wireless RS-232 pak didn't just wake up yesterday and discover the
>> 6551.  People who know how to write good software aren't afraid of the
>> 6551.
>>
>> My wireless RS-232 pak has been connected to 7 CoCo units (2 CoCo 1's, 1
>> CoCo 3, 4 CoCo 2's) and to 2 PCs @ 115200 bps running lengthy looping
>> tests (1-2 days sometimes), and I haven't seen it bomb out yet.  Can you
>> please tell me what circumstances I need in order to break my protocol ?
>
> I'm not a guru on all this but, it seems to me that if there was a bug in
> the original 6551, over the years it's been produced and cloned that
> somewhere, someone would have fixed it.
> I think Roger may be correct inasmuch that programming may have been the
> problem... although I don't know. It just seems that way because the 
> darned
> chip would have been fixed by now.
> I'm happy with my 6551 chips in my (OS9) coco. I'm not using Nitros9 so it
> would naturally be a little slower but, I've done megs of transfers 
> without
> incident..... I think.



--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco