Re: LZ: RAM I/O Expander
[Prev][Next][Index][Thread]
Re: LZ: RAM I/O Expander
On Thu, 12 Sep 1996 20:37:21 +0000, you wrote:
>I was just looking over the plans for the RAM IO Expander and it=20
>looks pretty good. The only thing is that it may be slow. The=20
>reason for this is that for every byte that the TI-85 wants to read=20
>or write, it has to transfer four (send 3, get 1 for read and send 4=20
>for write). What would greatly speed this up would be to have page=20
>writes or just have the TI-85 send three config bytes and in them say=20
>how many bytes to write or read and then just write or read that many=20
>without the three bytes. A couple ways to do this would be to add=20
>the ability to write up to 5 bytes at a time using the two leftover=20
>bits in the address, or increase the number of data bytes to 4 and=20
>have the last be the number of bytes. Either way would work fairly=20
>well. It may require a lot more work on the plans, but it would=20
>greatly speed up the transfer. Actually, the first way would=20
>probably work sufficiently and be easier to implement, but the second=20
>way would speed things up even more, but would require a lot more=20
>work. =20
>
It would speed things up, but the hardware overhead would be
tremendous. That would totally screw up the timer, and right now the
timer only works because the bytes are sent as multiples of 4.
However, as I mentioned earlier today the Microwire 1 Megabyte Serial
EEPROM is a totally new option for a RAM expantion. It will be faster
(and cheaper) to use the Microwire chip than the plans I have drawn
up. The expander I designed would therefore be best used as a
dedicated I/O and memory port (I'll have more on the Microwire
component tomorrow), but I'm not abandoning the expander. I have also
come up with a way to cut the chip count in half using the 74HCT299
instead of what I'm currently using. I'll post that soon as well.
>As an example, if the link port transfers at 9600 bps (BITS per=20
>second), then it can transfer a maximum of 1200 BYTES per second. =20
>Now, if you were to use the current plans, which require 4 bytes=20
>transfered for every 1 data bytes, then a maximum of 300 bytes per=20
>second can be transferred. If you were to use the first way=20
>mentioned, then can transfer 8 bytes for every 5 data bytes. This=20
>will speed up the transfer to a max of 750 bytes per second, which is=20
>150% faster than the current way (2.5 times as fast). This way is=20
>definately worth the extra work. The second way could transfer up to=20
>256 data bytes for every 4 config bytes. This would result in=20
>transfer rates up to about 1181 bytes per second. This is an=20
>increase of 294% (3.9 times) over the current plans and a 50%=20
>increase (1.5 times) over the first method suggested. If you are=20
>looking for the maximum transfer rates, then the second way is=20
>definately the way to go. And for those of you who are wondering how=20
>you can get 5 out of two bits, you are always going to send or=20
>recieve at least 1 byte so just add one to the value that is sent in=20
>the config byte. (00=3D1, 01=3D2, and so on.)
>
>
First of all, the only reason that the link port transmitts at 9600
bps is because that's what the standard RS-232 protocol uses. That's
fast enough for transferring pretty much anything you want. However,
the link port is, after all, a *port* and therefore it's probably some
sort of bidrectional latch in which the ROM uses to emulate a RS-232
compliant UART. The link port would be capable of transferring at
much higher speeds than it does while conforming to protocol. Like I
said in the docs, if you can get the clock cycle width down to 20 or
30 microseconds (which I believe is possible), you will have data
rates of around 6 kilobytes per second which translates to an actual
transferr rate of about 1.5 kilobytes per second. That number could
be faster or slower, I don't know yet. Also note that a 32k only
version of the Expander would be even faster, maybe 2-3k per second.
The circuit you're proposing would need some sort of address line
"auto-increment" system so that the bytes will be read/written in the
correct place. I suppose that's definitely possible, but again, I
believe the hardware overhead would definitely be increased, but it
would be faster. The biggest problem right now is synchronizing the
shift registers with the counter, and I really don't want to mess with
it (although the my new design may eliminate the need for counters).
Right now I'm leaning more towards the "easy to build" side than the
"performance" side.
-Thanks for your comments, feel free to reply.
-Mel
References: