**Previous message:**Andre Fachat: "Re: More than 256 sectors per track?"**In reply to:**Andre Fachat: "Re: More than 256 sectors per track?"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

On Thu, 16 Aug 2001, Andre Fachat wrote: > Instead of directly counting up or down I would recommend something > like a binary search, like first searching sector 256. If it works, go > up to 512 if not, down to 128. Repeat this until you have an upper and > a lower bound. Actually that is what I implemented on Monday evening. I haven't had time to touch the stuff after that (I've been working on my thesis), but it was pretty fast, probably less than 1 second/track when I let it swipe through all tracks and find the number of sectors on a 1541. For efficiency reasons, I used 8-bit numbers, so it'll only work for up to 256 sectors. I've been thinking about an optimization: what if the upper and lower limits are fixed to, say, half and twice the number of sectors found on the first track? The search could converge a little bit faster in that case. But I think I'll implement just this simple binary search first. I'll also simulate it with all possible outcomes, since I have bad experience from an integer-math 2-base logarithm function I wrote. In that search, I set low=current+1 or high=current-1, and one of the comparisons was so sloppy that a situation high<low was reachable. Marko Message was sent through the cbm-hackers mailing list

**Previous message:**Andre Fachat: "Re: More than 256 sectors per track?"**In reply to:**Andre Fachat: "Re: More than 256 sectors per track?"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Archive generated by hypermail 2.1.1.