On Friday 19 February 2010, Chris Hoogendyk wrote:
Gene Heskett wrote:
Can I plead oldtimers or something?
Not allowed.
I need to retain the hope that after a few more years I will still be
just as sharp as you are. Of course, that kind of begs the question of
whether I'm that sharp right now.
Thanks for the flowers Chris, there are times when I really need that boost
to my ego.
Right now, I am fighting with a driver for serial comm, using what can only
be described as "legacy hardware", the 6551 ACIA chip, running on a "legacy
computer", the TRS-80 Color Computer 3, in this case with a much smarter
Hitachi 6309 cmos cpu in it, and 2 megs of ram that it pages in and out of a
64k cpu address space as required. Its running the latest cvs pull of
nitros9, which is what the coco community now calls what used to be
Microware's OS9, and without diddling the clock speed has been optimized
until its about 2x faster that the original 'Level 2' version. The driver is
stable, and in the face of attempted buffer overruns, which it will not do
(finally), instead should exert some hardware flow control, but isn't.
At an rs232 speed of 9600 baud, an sz to rz transfer to this old slow machine
marches along at about 640 cps without any great amount of error corrections
being needed by rz. Crank it up to 19,200 baud, and the error corrections
limit it to about 150 cps over a full floppy disk image being moved. rzsz of
course manage to make the transfer perfect when done The correct value that I
write to the 6551's command register to drop the CTS signal (DTR on that end
I believe) I see on the led sniffer at this end of the cable has so far
eluded me, and I need to find it because I think I also have a flaky mc1488
in the interface that will occasionally _not_ bring it back true regardless
of how many times I write the correct signal to re-enable it in the 6551.
Failing miserably so far, so this is one of those times when I really do
appreciate the flowers, so thanks, a bunch.
OTOH, I just late last night, managed to get the driver to be stable despite
the overflow attempts, so now I am in a position to really go and beat it
about the brow with a real pi$$ elm club and make it truly bulletproof even
at much higher transport speeds. At least that is the target. I started
with some 20 year old level 1 (64k ram only) code that was IMO, much better
organized than the somewhat newer that is the std driver for this, which make
it both smaller and faster than the default mess of spaghetti. It has
basically 4 pieces of code, 2 in the IRQservice routine that handle the chip
and write buffer being empty, or the incoming buffer being full or the
outgoing buffer being empty, in which case it trys to wake the sleeping user
program, and the normal read, write and set config calls the outside world
can see. The read and write take care of emptying the read buffer, handing
the data back to the users program, and when nearly out of data, sends an xon
and/or resets DTR active low,, and the write portion taking care of telling
the writer to go take a nap when that write buffer is full.
--
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)
UNIX enhancements aren't.
