silverdr_at_inet.com.pl
Date: 2005-11-14 16:36:16
On 2005-11-14, at 13:58, Spiro Trikaliotis wrote:
[...]
>
> One remark: The schematics are a very valuable help, too. :)
>
I know. Just here I was lazy, especially that I remembered that I've
somewhere seen the table in question many years ago ;-)
>>> This is not the complete story. These delays accumulate. Thus, if
>>> you
>>> are "early" in reading one byte, you can be "late" in reading the
>>> next one. For example, Wolfgang Moser has done systematical tests
>>> and
>>> he found out that 41 cycles can still work, IF DONE PROPERLY. (!)
>>
>> I am not sure if I understand this...
[...]
>
> Ok, lets look in more detail:
[...]
Thank you for the excellent explanations. It seems that due to the
"three-stage" process, where only one stage is timed constantly one
can actually save some cycles on one byte in order to be able to
reclaim those on the next, during write operations. Very interesting
indeed. From what you wrote I understand that similar method can be
applied on reading:
0-------26-------52-------78-------
aaaaaaaa bbbbbbbb cccccccc dddddddd... disk/shift
xxxxxxxx aaaaaaaa bbbbbbbb cccccccc... via
xxxxxxxxxx aaaaaaaaaaaaaa bb cccccc... cpu
where between a and b one can have substantially more cycles to use
while having to "pay it back" (e.g. with pure sta zp_add) on the next
byte, right?
Best regards.
silverdr
--
'Concerns about "rights" and "ownership" of domains are
inappropriate. It is appropriate to be concerned about
"responsibilities" and "service" to the community.' -- RFC 1591, page
4: March 1994
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.