[Coco] "Did I do that?"

[Gene Heskett]

On Friday 03 May 2013 10:57:02 Bill Gunshannon did opine:

> > On Thursday 02 May 2013 22:18:55 Kip Koon did opine:
> >> Allen,
> >> Congratulations!  I didn't know you had done that either.  Heck, I
> >> didn't even know the Coco could talk directly to midi.
> > 
> > Not only that, Kip, but you can assign an output port to an instrument
> > on a
> > per instrument basis.  At one point, probably 17 years ago now, I had
> > 2 rs232 packs in mine, one with the crystal changed so it would run
> > at 31250 baud and drive a midi keyboard.  So I was sending some
> > instruments to a cz101 thru the rs232 port, and some to an MT-240 via
> > the bit banger.  A sneaky way to get around the 4 note polyphony of
> > the MT240 and the 8 note limit of the CZ-101 with those two
> > keyboards.
> > 
> >> Now to get a zillion slot Multipak so I can plug all this up together
> >> on my Coco 3!
> >> Has anyone made the 8-slot MultiPak yet?  If so, I'd like to buy a
> >> PCB from you so I can build my own.  Thanks in advance.
> > 
> > I looked at it, but the limited I/O space of the coco3 pretty much
> > killed that idea.  Sticking the GIME shadow registers smack in the
> > middle of what little I/O space we had was one of tandy's almost
> > unforgiveable blunders. The other was decoding only down to a $20
> > byte space.  Both of those blunders should have been hanging
> > offenses.
> 
> Never looked deep enough to see any of this.  Interesting.
> 
> So, a new question.  If the COCO design is flawed, what about looking
> at making the COCO4 :-) a totally new design using 6[83]09 without any
> of these shortcomings and then adding COCO emulation as a possible
> feature?  Don't know what it would take, but it could be a way to
> meet everyone's expectations and lower the complexity which would, in
> turn, keep the cost down a bit.  As well as allowing for even greater
> future expansion.
> 
> bill

Since this has turned into Yet Another Coco4(TM) discussion, I think yes, 
the absolute first thing I would do if to grab an FPLA big enough to decode 
the whole $FF00 to $FFEF range of I/O space into the required 4 byte wide 
CS pulses it needs & then just not bond out or wire up as the case may be, 
those addresses occupied by the odd but in conventional use.  To maintain 
compatibility, $FF7F (the mpi slot selector logic), and $FF90-9F would have 
to stay disabled, but that would still give us additional I/O space in the 
conventional 4 byte wide blocks.

Just in the $FF00-1F range alone, this would give us a new usable address 
range for I/O for 7 additional cards such as the rs232 packs.  Then in the 
$FF20-3F range another 7 such cards could be addressed. WP-RS screens too, 
once their screwed up, uses 8 bytes of I/O addressing because their base 
address straddles two of those 4 byte wide blocks.  Disk controllers, the 
floppy in particular are wasteful of I/O address space.

Unforch, doing this IN the coco would mean that our present cards wouldn't 
be usable because the side port connector would have to have about a 20 pin 
expansion just to carry all these chip select signals. SS-50 wouldn't be 
wide enough, and IIRC some of the SS-50 stuff was DMA related, which we do 
not have due to Moto's decision to make DMA in the 6xxx family into a 
separate chip.  The 6x09 does support the handshaking signals, but no use 
of them was ever considered for the coco.

Losing that port compatibility however is way way too high a price.  So I 
would propose an MPI like compromise for a new backplane std, to be 
designed into a new mpi like assembly, one which would decode the $FF04-1F 
block and present those 7 CS signals to the first 7 slots, then decode the 
$FF24-3F into CS signals for the next 7 slots.  That would be room for 14 
packs that had no address decoding of their own, all contained in the 
device descriptor.  That would give us 14 slots, 10 more than we have now, 
and we haven't even hit the legacy cards we all have that have their own CS 
decoding built in!

That would also demand a major re-write of a few bits of nitros9 because 
with that many devices, either the device table would be full, or we're out 
of sysram, which I am most of the time anyway.  Soo, one of the changes for 
this so-called level 3 of nitros9 would be to expand the idea of having scf 
devices in one map, the RBF devices in another, and all the assorted tables 
each device needs also moved out of the system map area into the correct 
scf or rbf mapped memory.  Replace those entries with a pair of copies of 
the GIME registers, to be copied to the GIME's 8 byte image of memory 
blocks. Which set gets copied to the GIME would be determined with whether 
its an scf module, or an rbf module that is about to be addressed.

How this would interact with the current dw3 drivers in the nitros9 kernel 
remains to be seen, since I've been told dw is both.  I'll let those who 
authored that code fill in those cracks in our knowledge base if they will.  
Perhaps a 3rd additional GIME map for dw stuff.  How this would impinge on 
the 128k coco3's out there looks iffy.  The half meggers should be fine, 
and I'd still have room for a 1.5 megabyte ramdisk on my machine.

Question?  New thread even: How many of Tony's 2 meg kits are still in use 
today?

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
There is much Obi-Wan did not tell you.
		-- Darth Vader
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.