[Coco] XMODE

[Gene Heskett]

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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>