[Coco] **JUNK** Re: 2022-06-10 Update on my CoCoIOn Ethernet Card Project

[gene heskett]

On Saturday, 11 June 2022 09:32:29 EDT Bill Gunshannon via Coco wrote:
> On 6/10/22 15:52, Michael Furman via Coco wrote:
> > I ended last week’s post with a riddle:
> > 
> > My CoCo needs to know what time it is and it can send and receive UDP
> > packets.
> > 
> > The Answer: We don’t need no steenkin’ Real-Time Clocks! 
> > Introducing: NTP on the CoCo
> > 
> > YouTube Video 1: NTP on the CoCo
> > https://youtu.be/eu2x6OmREF0
> > 
> > YouTube Video 2: Demonstration of the CoCOIOn Ethernet Card on a CoCo
> > 2 https://youtu.be/utCqwvolmEY
> > 
> > I wrote an ntpdate application for the CoCo that works with the
> > CoCoIOn Ethernet Card.  After the card is initialized with ccio -i
> > you can run ntpdate to set the system time.
> > 
> > GitHub:
> > https://github.com/n6il/cocoio-dw/releases/tag/20220610
> > https://github.com/n6il/cocoio-dw/tree/main/tests
> > 
> > Hardware From:
> > Computer Conect
> > https://computerconect.com
> > 
> > https://youtu.be/eu2x6OmREF0
> 
> This real time clock stuff reminded me of the work I did using a
> GPS receiver as a clock source for various Unix machines.  The
> same could easily be don for the COCO except for the limited
> number of available serial ports.
> 
> So, now the question.  Has anyone ever made or even considered
> a serial pack using the 16550?  It offers speed and efficiency
> and could probably be made addressable so that one could put a
> number of them (well, a couple) on a COCO allowing for even more
> fast serial connections with lower CPU overhead.  Seems like it
> would be nice for DriveWire.  Hmm...  Now that I think of it,
> you could probably make a board with more than one and add a
> bunch of serial ports.
> 
> Any serious flaws in this thinking?
flaws, but I don't know how serious you could label them but its just one 
of the reasons I have constant railed at the lack of adequate hardware 
decoding in the coco's hardware. there is room from $FF03 to FF1F for 7 
more pieces of i/o hardware, another 7 could be shoehorned in from $FF23 
to $FF3F, most disk controllers use 2 of the 4 byte blocks, the various 
clocks tend to use the $FF50 to $FF5F blocks, so we start at $FF60, with 
3 useable blocks because the mpi poisons the last block by useing $FF7F, 
and the coco3 gime steals the next 16 bytes.  So we are screwed out of at 
least 14 i/o devices by the choice of decodeing to only $20 byte wide 
chip selects in the coco's.

Any body who wants to expand that must first add the additional chip 
select decoding in the coco itself. That will involve trace cuts and 
such, and I've been reluctant to go down that path for obvious reasons.

The 16550 cannot be addressed adequatly in the 4 byte imterface structure 
defined in os9, it needs an i/o space 16 bytes wide. The only way I could 
fit that into os9/nitros9 would be to make the driver use the first byte 
of that 4 bytes available, would be to use it, along with some latching 
hardware around the chip to set which of the 16 registers actually gets 
the next control write. I started on such a project a couple decades 
back, and the driver rather quickly used up an 8k block of memory in my 2 
meg coco3. And it wasn't anywhere near functional yet. The std chip used 
in the serial pack ports we do have is so broken it takes difficult to do 
cut and paste mods to the pack to make it Just Work. And those 
instructions have gotten lost in the 25 years of time fog since. Possibly 
forever as drives have died since. And Boisy removed the sw patches for 
that in his rewrites of nitros9.

Take care & stay well everybody.

> bill


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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis