[Coco] RS DOS RS232 application?
L. Curtis Boyle
curtisboyle at sasktel.net
Fri Apr 15 11:20:04 EDT 2016
Yes, the “stack blasting” technique is by far the fastest way to move/copy blocks of contiguous memory around on a 6809. On the 6309, TFM is much faster than that.
L. Curtis Boyle
curtisboyle at sasktel.net
> On Apr 15, 2016, at 9:15 AM, Dave Philipsen <dave at davebiz.com> wrote:
>
> I just mentioned that because I remember doing some research a long, long time ago on how to clear a CoCo 3 graphics screen in the quickest way. It seems like I ended up using pshu for that. If you think about it, a pshu is very similar to a std ,x++ except that you can move more than two bytes at a time.
>
> Dave Philipsen
>
>> On Apr 15, 2016, at 1:43 AM, Gene Heskett <gheskett at wdtv.com> wrote:
>>
>>> On Thursday 14 April 2016 22:42:10 Dave Philipsen wrote:
>>>
>>> Have you compared the pshs/u puls/u instructions for moving data
>>> quickly?
>>
>> No I haven't Dave. I did look at the cycle counts a long time ago, and
>> ldq/stq were a fewer cycles less on the 6309 as it skipped the 2nd
>> instruction fetch on the 6309. And moved 4 bytes at a time, so I just
>> used the 6809 equ that moved 2 bytes at a time if that is what its
>> running on. For incoming or outgoing data thru a 6551, if a 4 byte fifo
>> in hardware could be built that only its driver knew about, that would
>> handily demolish the timeing requirement of clearing the 6551 read
>> register before the next byte was clocked in. Frameing errors would
>> melt away till at least 2x the speed on a 6809.
>>
>> This is also a major roadblock to the use of rzsz at higher speeds
>> because the current implementation is a one byte at a time monster. And
>> it cannot deal at all with a data window bigger than 256 bytes. I
>> should have been working on Tim K.'s code, which I think could handle
>> the bigger block sizes. Putting the table lookup cnc method into that
>> should have resulted in at least a 2x speed improvement like it did for
>> rzsz. But we have better phone lines today, so its extreme error
>> correction ability that results in the speed limit, is IMO wasted.
>>
>>> Dave
>>>
>>>> On 4/14/2016 7:14 PM, Gene Heskett wrote:
>>>>> On Thursday 14 April 2016 19:58:35 RETRO Innovations wrote:
>>>>> I would like to test out a mod to my RS232 pak to bring it up to
>>>>> 230kbps. Is there a simple app around that has source so I can
>>>>> modify it to do 230kbps on my rs232 pak and test? Or,
>>>>> alternatively, is there a simple terminal that I can run to test
>>>>> out the various existing bps rates?
>>>>>
>>>>>
>>>>> Jim
>>>>
>>>> Unless you have huge buffers, big enough to contain the whole
>>>> transmission, the coco cannot move more than about 90k a second.
>>>> That corresponds to the megaread times I was able to get from myram,
>>>> of 11 seconds for a megabyte on a 6309, and just over 13 seconds on
>>>> a 6809, each using the fastest way to move data that exists on those
>>>> 2 processors. For the 6809, thats (after the transfer is setup)
>>>> ldd,x++; std, y++, or for the 6309, ldq ,x++;stq ,y++ (IIRC).
>>>>
>>>>> --
>>>>> RETRO Innovations, Contemporary Gear for Classic Systems
>>>>> www.go4retro.com
>>>>> store.go4retro.com
>>>>
>>>> Cheers, Gene Heskett
>>
>>
>> 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>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
More information about the Coco
mailing list