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.