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.
