[Coco] Utility of large MPI (was: Re: ROM Cart registers)

[Steve Pedersen]

Midi would be nice as would Bluetooth for drivewire. Since I am dreaming
how about Ethernet , I know the c64 has an open source design for a
controller. The schematic and everything is on the web. If such a cart did
exist I in a hartbeat get a real CoCo setup space be damned I just cant run
a bunch of wires all over the place from my pc to where my coco would have
to go. some sort of wireless connectivity would make owning a real coco
doable for me. a little off topic but are there any wireless solutions
available right now ?

On Tue, Feb 2, 2016 at 10:33 AM, Camillus <camillus.b.58 at gmail.com> wrote:

> Why not integrate the diskcontrollers ( floppy, ide, etc, etc ) straight
> into the coco design, so that the range FF40-FF5F can be used solely for
> cartridge I/O. There has to be a chunk of 16 addresses somewhere in the
> coco's memory map that can be decoded for the controllers?
>
> just my $0.02
>
> cb
>
> Sent from Mailbird [
> http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm_campaign=sent-from-mailbird
> ]
> On 2/2/2016 12:21:24 PM, RETRO Innovations <go4retro at go4retro.com> wrote:
> My comment was more around the utility of such a device in the context
> of existing HW (no driver changes/rewriting). The only value the MPI
> provides is to select among existing devices that reside in $ff4x, which
> is mainly:
>
> FF40:FF4F
>
>
>
> FD-502 (FDC)
>
>
>
> Floppy Drive Controller (all?)
>
> FF40:FF5F
>
>
>
> Color Burner
>
>
>
> Dennis Kitsz' Color Burner
>
>
> Otherwise, a Y cable would be just as useful (a 4 tap cable, or 8 tap)
> and be significantly cheaper. Maybe a Y cable with some buffer/driver
> ICs to beef up the address/data/control line integrity.
>
> I'm just thinking what is needed is a next generation MPI, with possibly
> an MPI-emulator mode, where:
>
> * Each port is truly isolated. If you have selected slot #3, then
> slot #3 (and only slot #3) is connected to the Coco. Each cart
> would be completely isolated from any other cart.
> * In MPI-emulate mode, only CTS, CART, and SCS would be isolated.
>
> Of course, in this case, any software that is not MPI aware would need
> to be modified (I would assume HDB-DOS is top of the list) so it would
> select the correct slot before executing any code.
>
> It's not terribly hard to modify the MPI design to support full
> isolation (essentially, the quickest option would be to put 3 state
> buffers on some activity lines like E and Q, and put a buffer on DATA.
> BUt, with buffers on each individual data line on each individual slot,
> You'd need to mux all of the data ports on a read cycle (since you'd
> have no idea which slot is driving the DATA bus). That adds a lot of
> complexity.
>
> At that point, it's probably cheaper/better to simply make a super IO
> cart, like used to be on PCs.
>
> * Glenside IDE
> * CocoSDC
> * ROM
> * serial
> * RTC
> * centronics parallel?
> * not sure what else (sound generator?)
>
> Of the above, IDE, serial, parallel, rtc, and flash are easy, looks like
> you have FDD figured out, and not sure what else folks would need. With
> an MPI, you'd still have options for Speech, SC-90, special purpose
> existing carts, etc. paks.
>
> Just thinking out loud.
>
> Jim
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>



-- 
Those who can make you believe absurdities can make you commit atrocities.
- Voltaire
Duty is heaver than a mountain, Death is lighter then a feather. - Imperial
Rescript