LZ: Re: RAM I/O Expander
[Prev][Next][Index][Thread]
Wait a sec.. Wait a sec... lets get the RAM I/O expander actually working
and see how fast it goes and if it even works before we start questioning
it. By looking at the schematics, it looks very feasible. I'm afraid that
if we starting commenting about how slow it is and stuff, people will start
to look down on it, people will start to doubt it, and basically, no one
would really care about it anymore. It would be a MAJOR revolution in
calculating if we could add 8 megs of memory and a modem. Even if it did go
at 300 bytes per sec, why do you need all that speed?? If you keep all the
needed progs in the TI memory, then it won't matter. I would just use the
expansion for backup and stuff like that. Even at 300 bytes per sec, it
would still be relatively quick considering that most of the programs are
only about 3k any ways. So anyways, lets see if it works, then critique it,
not critique it before we see it.
-greg
----------
> From: Ed Plese, Jr. <eplese@lnd.com>
> To: list-zshell@lists.ticalc.org
> Subject: LZ: RAM I/O Expander
> Date: Thursday, September 12, 1996 4:37 PM
>
> 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
Follow-Ups:
References: