[Coco] CoCo and Rasberry Pi ( and Software Rant )

[David Ladd]

Actually at one point I was hoping to create a becker/boisy interface cart.
that would use
http://www.saelig.com/USBO/U013.htm
for the virtual serial port on the PC.  Then the interfacing logic to the
TTL side of this device I diagrammed out as being possible to do.

The problem I ran into was the logistics of actually creating it. I had a
few 74LS type chips to do the addressing decoding for both status port and
data read/write.  Mark told me it would be better to invest into CPLD chips
which I looked at and he is right.  So it is very possible to create a
becker/boisy interface cart.

I myself just don't have the resources in place to even beginning to invest
in a venture like this.  One of the groups, that are on the list, which
have schematic layout software and board layout software would probably be
ones that might have to pick this up.  Also I don't have the
diagnostic/data analyzers to verify that everything is working as intended.

At some point I might still try doing a wirewrap prototype using a Glenside
IDE board as those have 2 (40pin) IDE type solder pads on them for someone
adding cart slots onto them.  So was thinking of putting a 40pin connector
on one of them and then wirewrapping something onto it.

hopefully someone with the skills and backing will jump on this.  Just from
looking at what I have researched it should be very possible to do.



On Wed, Apr 10, 2013 at 5:32 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:

> The power situation is a concern.  I believe a lot of the Pi's power
> requirements are to drive it's USB ports, which would not be in use in
> the scenario I'm thinking of.. maybe that would help?  I suppose
> separate power or major changes to the coco is possible, but it would
> be awfully nice to have something that could just plug into any
> regular coco.
>
> The Pi is just one step in a long road of smaller, faster, cheaper,
> better..  maybe it's not quite where we need it on some axis.
>
> -Aaron
>
>
> On Wed, Apr 10, 2013 at 7:28 AM, Frank Pittel <fwp at deepthought.com> wrote:
> > I here a lot about "plugging" a pi into a coco and always wonder if the
> coco
> > power supply has enough power drive it. The specs I've seen shows that
> the model
> > A uses 300ma and the model B uses 700ma. That seems like a lot of power
> for the
> > undersized PS in the coco!! One possible solution would be to "dump" the
> internal
> > supply and use a wall wart type supply to power the pi and coco. I've
> got a couple of
> > usb supplies that put out 5V at 2.1 amps and I've seen some that put out
> 3A.
> >
> > The Other Frank
> >
> >
> >
> >
> >
> > On Wed, Apr 10, 2013 at 10:01:26AM -0400, Brett Gordon wrote:
> >> I propose this:
> >>
> >> A Rasberry Pi running DW interfaced into the coco via an interrupt
> >> driven 8 bit becker/boisy port, with some Flash ROM similar to
> >> SuperIDE.
> >>
> >> Why a Pi ?   Your coco could use anything that Linux supports via USB:
> >> keyboard, mouse, joystick, harddrives, smartcard readers, MMC/SD Flash
> >> readers, Serial Ports.  Oh yeah: I guess the Pi's HDMI and Composite
> >> Video is there too.  Let's use the Pi for some cool graphics!  ( I
> >> believe DW4 has some basic support for this, BTW).  Oh yeah the PI is
> >> amazingly cheap.
> >>
> >> The Flash ROM solves a very basic software problem we have: it's plain
> >> crappy to boot the CoCo:    it's entirely static.  ROM: that's all you
> >> have.  Even after you boot from ROM you get a static enviroment:  both
> >> RS-DOS and RBF systems have NO SUPPORT FOR PARTITIONING.  This is
> >> stupid. Disk Partition Tables have been agreed upon and in use in the
> >> MAC/PC world since the late 1970's.  It is unacceptable and poor
> >> programming practice that our two main OS's don't support partition
> >> tables.  The most hideous part of writing the HDB/IDE drivers for the
> >> original CoCoBoot was the fact that I had to rely on the USER knowing
> >> or grokking around in ROM to manully tell me where a HDB partition
> >> might sit (AKA the HDB-OFFSET ).  This is plain wrong. ** We now have
> >> open-source HDB-DOS, and a open-source Nitros9.   It's time to drop
> >> the legacy of crappy software design.
> >>
> >> Why an interrupted 8 bit becker/boisy port?  8 bits is our inherent
> >> data bus on the 6809.  16 bits would be a touch faster on the 6809,
> >> but 8 bits is more doable on the Pi than 16 bits.  Yes, DMA would be
> >> awesomely faster, but has two drawbacks: (1) unless the DMA controller
> >> could put drive data exactly where our OS's want it, then its no
> >> faster than a plain becker/boisy port. and (2) this is complicated.
> >> ***
> >> Modern OS design calls for a Hardware Interrupt, NOT polling.
> >>
> >>
> >> --
> >> Brett M. Gordon,
> >> beretta42 at gmail.com
> >>
> >>
> >> ** Beretta's Rules of Programming No. 2. Computers count well, people
> don't.
> >> *** Beretta's Rules of Programming No. 9: Simplicity Good!  And rule
> >> No. 10: Complexity Bad!
> >>
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> http://five.pairlist.net/mailman/listinfo/coco
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>