[Coco] RS232 Pak needed

[Louis Ciotti]

Wouldn't it be better to just implement a 6551 in a CPLD or FPGA, keeping
it backward compatible with older software, and maybe implementing
improvements/other options accessible via the control register.




On Fri, Sep 20, 2013 at 4:07 AM, Steve Bjork <6809er at srbsoftware.com> wrote:

> Picaxe are great for a quick and dirty test or small production of
> something.  But making a project with orders of 50 or more, I would use a
> pic or some other micro-controller with a lower cost than the Picaxe's
> $3.50.  (more like $0.75 each)
>
> My first step is take a look at what you are trying to interface into the
> CoCo.  If we are looking at just older RS-232 device then making a
> replacement for the old RS-232 Pak is the direction we should go.  The cost
> of goods to build this type of board would run under $7.50.   The "hard"
> part of doing this project is writing the code to make the Pic chip think
> that its a 6551.  One option that we could add would be a large I/O buffer
> with full hardware handshaking.  That could speed up the I/O.
>
> Steve
>
>
>
> On 9/19/2013 11:21 PM, Gene Heskett wrote:
>
>> On Friday 20 September 2013 01:26:01 Steve Bjork did opine:
>>
>> I am with you 100% Steve.  There is so darned much breakage in the 6551
>> that we have tried to write code around for 30 years now, without anyone
>> doing anything to rectify the fact that it has more bugs than a 10 day old
>> carcass alongside the road.  That chip should have been binned the instant
>> a better one came along.  IMO the 16550 is not it as it ties up 16 IO
>> addresses to properly handle it, so thats a no go from the gitgo
>>
>> With the pikaxe running from its own teeny little os in flash, all we'll
>> need to see are the 4 data & configuration port registers so it looks most
>> like the 6551 but actually has working flow controls.  With a 2nd, 4
>> address wide port into its flashrom, even that could be updated by the
>> coco.
>>
>> But I'd put a flea clip onboard write disable on that in case the coco did
>> a confetti screen too.
>>
>> If you can send me the eagle files to build this serial port function,
>> preferably 2 or 3 up on one card, while staying inside the 4 address limit
>> for most coco i/o per instance per port, I will make the first 2 cards on
>> my milling machine.  If it works, the eagle files goto somebody in Hong
>> Kong for enough copy's to fill the needs at 1/8 the cost for me to
>> actually
>> produce them in gty's.
>>
>> Two gotchas for those 1st cards. (1 for you, 1 for me to be used as test
>> mules)
>>
>> I cannot do plated through holes, so tsop packages would at least solve
>> that dip chip problem.  Any other thru via's needed, a bit of wire will
>> make these breadboard, proof of concept cards work.  If someone can do the
>> eagle files, I can do the rest, ready for part soldering. I have done
>> simple stuff (like the spindle encoder in my cnc lathe) in eagle but a
>> younger mind than my rusty wet ram will probably do it faster for the more
>> complex layouts.  It will be 79 the next time the date string says the 4th
>> of the month. Stuff like this "keeps me out of the bars". :-)
>>
>> Forget the DB25 connectors, the 7 wire protocol thru a db9 connector has
>> been the default method for 20 years now, and saves acres of board space.
>>
>> As evidenced on this list, there IS a market for rs-232 port cartridges.
>> But one per "pack" is never enough.  If the 2nd one isn't going to be used
>> as a serial mouse port, which fixes the spastic mouse with one that puts
>> the click exactly where the pointer is, then it could be made into a midi
>> port, so the baud rate register should include 31250.  I have done both at
>> various times, currently using the 2nd port for a mouse, a full 3 button
>> mouse.
>>
>> What say you, Steve?
>>
>> Cheers, Gene
>>
>>
>>
>
> --
>
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>