[Coco] RS DOS RS232 application?

[Dave Philipsen]

Another thing to consider is the CoCo3FPGA which synthesizes a 6809 at 25 MHz.  I was playing around with Gary's implementation of a 640x450 256-color graphics screen which requires a whopping 288,000 bytes of memory (more than half of the onboard 512k). Clearing a screen of that size also requires keeping track of an address which is larger than 16 bits.  But at 25MHz the processor deals with it quite handily even if you don't use the most optimal method.

In addition to that Gary has some neat hardware features he's added that help with the manipulation of large areas of memory.  There is a 24-bit direct memory access method that bypasses the MMU and has an auto-increment feature that can be turned on and off.  So, for instance, you could store the 24-bit starting address of the graphics screen in the registers, turn on the auto-increment feature, and then simply issue a string of STAs 288,000 times to clear the screen.  You could also switch the direct page to the I/O area ($FF) and use direct addressing to do it even faster.  This is all done while maintaining backward compatibility with the CoCo 3/GIME scheme.

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