Re: LZ: RAM I/O Expander
[Prev][Next][Index][Thread]
Re: LZ: RAM I/O Expander
Here's just another idea. You might want to send large numbers of bytes
for xfering, and while 5 at a time is good, more would be better. So why
not just have those 2 digits instead of adding anohther byte to be
xfered, instead set a multiple of a constant. i.e. 00 is 1 byte, 01 is 8
bytes, 10 is 10 bytes, etc... Just a thought.
<pre>
---
site ignore
On Thu, 12 Sep 1996, Ed Plese, Jr. wrote:
> I was just looking over the plans for the RAM IO Expander and it
> looks pretty good. The only thing is that it may be slow. The
> reason for this is that for every byte that the TI-85 wants to read
> or write, it has to transfer four (send 3, get 1 for read and send 4
> for write). What would greatly speed this up would be to have page
> writes or just have the TI-85 send three config bytes and in them say
> how many bytes to write or read and then just write or read that many
> without the three bytes. A couple ways to do this would be to add
> the ability to write up to 5 bytes at a time using the two leftover
> bits in the address, or increase the number of data bytes to 4 and
> have the last be the number of bytes. Either way would work fairly
> well. It may require a lot more work on the plans, but it would
> greatly speed up the transfer. Actually, the first way would
> probably work sufficiently and be easier to implement, but the second
> way would speed things up even more, but would require a lot more
> work.
>
> As an example, if the link port transfers at 9600 bps (BITS per
> second), then it can transfer a maximum of 1200 BYTES per second.
> Now, if you were to use the current plans, which require 4 bytes
> transfered for every 1 data bytes, then a maximum of 300 bytes per
> second can be transferred. If you were to use the first way
> mentioned, then can transfer 8 bytes for every 5 data bytes. This
> will speed up the transfer to a max of 750 bytes per second, which is
> 150% faster than the current way (2.5 times as fast). This way is
> definately worth the extra work. The second way could transfer up to
> 256 data bytes for every 4 config bytes. This would result in
> transfer rates up to about 1181 bytes per second. This is an
> increase of 294% (3.9 times) over the current plans and a 50%
> increase (1.5 times) over the first method suggested. If you are
> looking for the maximum transfer rates, then the second way is
> definately the way to go. And for those of you who are wondering how
> you can get 5 out of two bits, you are always going to send or
> recieve at least 1 byte so just add one to the value that is sent in
> the config byte. (00=1, 01=2, and so on.)
>
> I don't know what you think of this, but I think Mel Tsai would be
> willing to think about one (if not both) of my suggestions.
>
> -Ed
>
</pre>
References: