[Coco] XMODE

[Tim Fadden]

On 3/7/2017 11:38 AM, Gene Heskett wrote:
> On Monday 06 March 2017 22:51:03 Tim Fadden wrote:
>
>> On 3/6/2017 7:09 PM, Gregory Law wrote:
>>> This is from scf.d in the defs folder. I'll get these transferred
>>> into the technical reference in the WIKI as well.
>>>
>>> * PD.PAR definitions
>>> *
>>> * Parity
>>> PARNONE        EQU       %00000000
>>> PARODD         EQU       %00100000
>>> PAREVEN        EQU       %01100000
>>> PARMARK        EQU       %10100000
>>> PARSPACE       EQU       %11100000
>>>
>>> * PD.BAU definitions
>>> *
>>> * Baud rate
>>> B110           EQU       %00000000
>>> B300           EQU       %00000001
>>> B600           EQU       %00000010
>>> B1200          EQU       %00000011
>>> B2400          EQU       %00000100
>>> B4800          EQU       %00000101
>>> B9600          EQU       %00000110
>>> B19200         EQU       %00000111
>>> B38400         EQU       %00001000
>>> B57600         EQU       %00001001
>>> B115200        EQU       %00001010
>>> * Word size
>>> WORD8          EQU       %00000000
>>> WORD7          EQU       %00100000
>>> * Stop bits
>>> STOP1          EQU       %00000000
>>> STOP2          EQU       %00010000
>> Hi Greg.
>>
>> Every thing here matches up with the docs I have for an older version
>> of xmode.
>> It called the par option type along with a few other name changes
>>
>> One difference I did see was that under the baud rate, STOP2 was in
>> bit 7, and bit 4 is marked reserve.
>>
>> Also PARMARK shows the below instead
>>
>> PARMARK        EQU       %10000000
>>
>> and miss is:
>>
>> modem kill  toggled with bit 4
>>
>> So, was the old version wrong, or the new one, or did these get
>> changed/dropped?
>>
>> I will see if I can test the stop and mark tomorrow, and let you know.
>>
>> --
>> Tim Fadden
>> "Hey Schmidt, don't forget about the six P's.
>> Proper Preparation Prevents Piss-Poor Performance!"
> One other thing that I've noticed, is a total lack of any mention of a
> patch, and a hardware hack to the 232 packs, that when done, enables
> true 7wire flow control. We have not had that in any nitros9 driver for
> the 232 stuff in better than a decade. So anytime I use the pack to move
> a big file like a .dsk to my coco3, I find I have to restrict the speed
> to about 4800 buad, and limit the window size to 256 bytes on the linux
> side else it overflows and rxsz takes minutes to sort it out and restart
> the data flow, so the transfer is actually quicker done by slowing it so
> that overflow never occurs. The fact that data keeps coming in even when
> the xoff has been sent or CTS has been dropped can be verified with any
> of the rs232 testers the shack used to sell years ago.
>
> I don't know who decided to drop that define from the xmode stuff, but I
> have been upset about it for years.
>
> That patch and the instructions on how to patch the rs232 pack to make up
> for the fact that the 6551 is a basically broken chip in regard to flow
> control are available on my web site. It was fun moveing data at 9600
> baud back when I was running an amiga nearly 20 years ago, flow control
> worked flawless then with rzsz makeing an average of 720 bytes a second.
> Because it doesn't work now, even with my patched pack, has been a
> bummer since forever it seems. In that regard, drivewire has been a
> lifesaver here.
>
> Those patches and texts describing them are:
>
> CTS2DSR_mod.txt
> README.Sacia.PrJ
> SAcia_High_Speed_Patch.lzh
> SAcia_hi_mps_ctc.ipc
>
> Available in the usual Genes-os9-stf subdir on my web page in the sig
> below. I doubt the ipc is any good now since its been renamed to
> sc6551.asm in the sources, but the idea is still 100% valid. So lets get
> it back into the nitros9 sources, this time for good.
>
>
>
> Cheers, Gene Heskett
I have the same experience Gene.

I can't get any of the options for parity to work at all.  8bit None and 
one is the only thing that works other than changing the baud rate which 
still works.

Making me think to dump the current version of nitros9, and going back 
to what worked.  Speed is fine, but everything working as it should is 
more important to me.

ya drivewire and scd is great, but why drop the functionality of the 
original hardware?

Guess I am too old school. :-)

-- 
Tim Fadden
"Hey Schmidt, don't forget about the six P's.
Proper Preparation Prevents Piss-Poor Performance!"