[Coco] Shell i=/t1& slowdown

[Gene Heskett]

On Friday 07 September 2007, Willard Goosey wrote:
>>Date: Thu, 06 Sep 2007 09:12:10 -0400
>>From: Gene Heskett <gene.heskett at verizon.net>
>>
>>And the serial mouse is the single biggest improvement you can make
>>to using a mouse on the coco.
>>
>>As for the driver for the mouse, that was part of a cc3io conversion and I
>>don't believe that code survived past about 1.17 of nitros9, a decade or
>>longer ago.
>
>The are drivers are in Nitros9 for serial mice.  One for logitech
>protocol and one for microsoft protocol, and a version of each for a
>6551 or 6552.  Rather any of this is still your code...

Unforch, all of my rs232 stuff, and the wp-rs I used for the 2nd monitor, have 
all had their hardware addresses 'adjusted' to fit the VERY limited I/O 
addressing space the coco3, with its hunger for a section of that valuable 
real estate for the gime's use, and level 2 os9 ISTR made using that area 
above the gime's less than appetizing.  ISTR the top $40 bytes were again off 
limits due to the automatic rom accesses there for IRQ handling, or some such 
but my memory is pretty hazy after all these years.

>>Likewise the incorporation of the co80 code so a 2nd monitor could be used
>>also seems to have fallen by the wayside.
>
>Oh wow!  That's cool.  The GIME didn't melt?

The gime wasn't involved with that at all, the WP-RS cartridge that drove a 
Maggy PC-80 amber screen monitor was just another 4 byte wide I/O port, which 
for some reason totally beyond me, straddled a 4 byte boundary, using 2 bytes 
of each 4 byte block.  As there was an extra gate on the card, that obviously 
got fixed.  But all that was hard coded in the driver, with only the base 
address in the descriptor.  The driver had to rebuilt to use the new offsets 
from the descriptors base address obtained at init time.

Rant mode on...

Actually, there is quite a bit of I/O addressing space available in the coco3 
if one could handily access the scs decoding and kill it except to the 4 
bytes starting at $FF00, and $FF20.  And to compound the felony, and a felony 
it was, the stock disk controller, which needed 8 byte sized addresses, was 
also defaulted to a 32 byte wide response block.  Mistaken design choices 
there wasted another 24 bytes, room for 6 more of these 4 byte wide devices.

The shacks laziness in designing that cost us 80 bytes of what should have 
been usable I/O space below $FF7F ($FF7C-FF7F blocked by the mpi although the 
other 3 bytes might have been usable.).  In the usual 4 byte wide coco 
hardware, that's room enough for 20 more 4 byte wide devices!

/Rant mode..

I think the main reason this was never done is because it would have been a 2 
part kit in some cases, one part to be installed in the coco3 to disable it 
for the ghosted but invalid addresses, and one part in each cartridge that 
didn't have that fine grained an address decoder in it.  Most however did 
have proper decoding but at the wrong address to peacefully co-exist.  Since 
there were more cards than available addresses, it was up to each of us to 
find his own solution for these addressing clashes.  Generally, the driver 
would be happy if the descriptor was updated, the singular exception to that 
being the WP-RS I have which required the driver rebuild when I fixed its 
address decoding.  I also had a WordPack II, which was a similar card but in 
a much cheaper cream colored blow-molded case but I didn't investigate it all 
that much and I believe I sold it, probably to someone here at the time.  I 
didn't have a schematic for that one unforch.

The WP-RS has a rather extensive lookup table that the driver loads into the 
chip at init time, and some of these can be adjusted to make the working part 
of the WP-RS screen considerably larger by reducing the blanking area around 
the text and adding a 25th line of text, all that can be supported in its 
measly 2k of ram.  I made liberal use of those adjustments, the downside 
being that the pixel clock was fixed, so the synch rates went up, the 
vertical to around 70hz, and the horizontal to something in the 18khz range.

As that was faster, the pc-80 never complained nor was it in danger of a 
meltdown.  Its going too slow that kills things in the h-scan because slow 
gives the ferrite time to saturate.  When that happens, the currents rise to 
many amps in a microsecond, with the usually predicted results, the plastic 
mirror pops and the smoke that makes it all work gets away. :)

>Willard

-- 
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)
"It's ten o'clock... Do you know where your AI programs are?"  -- Peter Oakley