[Coco] A new idea for a CoCoSDC expander

[Gene Heskett]

On Tuesday 14 October 2014 23:41:50 Bill Pierce via Coco did opine
And Gene did reply:
> Ed, as far as I know, no one has ever built and tested?John's 8 slot
> expansion, or his 4-slot RS "clone" for that matter. I don't think
> John ever built one himself. He just did the design. He disappeared
> right after he made those posts to coco3.com. He also had Orch90,
> RS232, and FDC clones as well. Tom Gunnison has a 4 slot design that
> he HAS built but it's a little bulky compared to John's design. I also
> like John's idea of a "controller" that plugs into the Coco, cabled to
> a "main module" with the slots. ?
> ?
His 8 slotter was something I would like to try laying out in eagle, but 
thats a big enough board to need a full license.  But the first copy would 
need to be wire wrapped to bug check it.

> As for MPI "clones"... look through the old Rainbows, Color Computer
> Magazines, and Hot?Cocos, and you'll find 10-15 (if not more)
> different models that have been put out through the years.? Eveything
> from a simple "buffered slot expander" to a full blown unit with 1 meg
> of memory, built-in floppy and HD controller, 2-4 RS232 ports,
> P-Printer port etc. There have been many; from homebrews to "nicer"
> than Radio Shack's model.
> 
Another consideration when we are playing this seemingly endless "what if" 
theme, is the size of our machine.  All these things take kernel code to 
run them, and we'll run into sysram limits long before we get enough stuff 
in a kernel/os9boot file to adequately drive all 8 slots of the little 
John design.  That, and the almost criminal waste of I/O space caused by 
the incomplete decoding of CS signals in the basic coco.

My attitude about a new run of MPI's is that the existing design can and 
should be simplified, the IRQ handling in particular.  What this would do 
to its usefulness in RSBasic has not been well researched by me because I 
really don't care about basic as it has limitations that disappear when 
Nitros9 is loaded.

The os9boot file size limits could be handled nicely by drawing oneself up 
a map of what vdisk contains the drivers you want to use at the instant, 
and running an mb against that vdisk to generate that bootfile.  Then, 
when you want to autoboot from the HD and use that particular bootfile, is 
just a matter of looking up in your map, the right vdisk to boot from, 
then "bootlink vdisk-number" which can be in the format of $80 or decimal 
128 as a for example. Then its a matter of tapping the reset button to 
reboot to that selected os9boot file. bootlink opens things up a bit by 
making it easy to load a customized boot for a particular job.

So would making the level 3 stuff work, however I don't believe that can 
be done and drivewire survive because it has no 'fences' between RBF and 
SCF.

My thoughts on a level 3 run in an entirely different direction simply 
because the sysram limit is such a limitation. I have been intermittently 
thinking of a way to give each of the hardware drivers its own 8k block of 
ram that is not subtracted from the kernels sysram, probably by adding 
another allocator module to the kernel that each driver could call to get 
its own working ram from the pool, something that could be done even in a 
half meg machine but would need at least the half meg.

However, that would be a long slog redoing drivers to make use of it, but 
it would probably, if fully done, give us as much as 24k of sysram by 
taking that drivers scratchpad memory out of sysram and into its own 8k 
block!

I'm still working out the details, and it may never happen, but I'll 
probably start with the additional two kernel functions, wrappers for 
calls already there, to handle it on a per driver basis, and use the 
existing hardware deluxe 232 driver as a guinea pig.  On my system, its a 
bit constrained trying to work in the 1k of ram setting because that ram 
comes out of sysram.

Because the driver would be entered without that valid memory assignment 
for each of the 6 normal functions, the first thing it would have to do is 
make that call to get its own memory, and rewrite those 8 slots of the 
gime that map it into the normal space.

I would probably use self modifying coding to save and retrieve its block 
assignment. Its already being done in the TC^3 driver to save its slot in 
the mpi, and has worked perfectly for about 3 or 4 years now.

The reason for using the existing 232 driver is that it would also serve 
as an interrupt latency testbed at the same time. The nominally 15 
microsecond IRQ latency would be stretched several 10's of microseconds 
while doing that housekeeping, and that would be the acid test to see if 
its a good concept. I know for a fact that this latency can be stretched 
by at least 100 microseconds without throwing an overrun flag in the 
sc6551 chip we use on a 9600 baud signal.  It remains to be seen how long 
a delay the housekeeping would add, but I have a new 100mhz dual channel 
digital scope that should make it much easier to measure that.  I tried it 
out on the drivewire signals and measured the baud rate on my CC3, getting 
something in the high 114kb (s/b 115.2Kb) range, which is far enough off 
that I have 2 new usb-ser converters that will not work with DW at all. 
Possibly the crystal in my coco is ageing flat, that is not impossible!

> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
> ?
> 
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Webmaster of The TRS-80 Color Computer Archive
> http://www.colorcomputerarchive.com/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
> 
> 
> 
> 
> -----Original Message-----
> From: Zippster <zippster278 at gmail.com>
> To: CoCoList for Color Computer Enthusiasts
> <coco at maltedmedia.com> Sent: Tue, Oct 14, 2014 11:22 pm
> Subject: Re: [Coco] A new idea for a CoCoSDC expander
> 
> 
> 
> 
> I read about half way through the info on this one so far.
> 
> Was this one ever completed/produced?
> 
> I like the 2 board concept.
> 
> - Ed


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS