Re: Fast GCR decoding?

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.