Re: Commodore 15 Second disk format routine disassembled

Hi all,

> On Jun 19, 2026, at 5:37 AM, groepaz <groepaz_at_gmx.net> wrote:
> 
> Am Freitag, 19. Juni 2026, 14:14:33 Mitteleuropäische Sommerzeit schrieb
> Francesco Messineo:
>>> On Fri, Jun 19, 2026 at 1:58 PM groepaz <groepaz_at_gmx.net> wrote:
>>> Am Freitag, 19. Juni 2026, 09:34:14 Mitteleuropäische Sommerzeit schrieb
>>> 
>>> Francesco Messineo:
>>>> On Fri, Jun 19, 2026 at 12:37 AM Maciej Witkowiak <ytm_at_elysium.pl>
> wrote:
>>>>> In its extended format disk the disk will have tracks 35-41 formatted
>>>>> and
>>>>> it reports 840(!) free blocks.
>>>>> 
>>>>> It not only formats the inner tracks, but, if I got the disassembly
>>>>> right,
>>>>> the whole disk is formatted with the same density as tracks 1-17, with
>>>>> 21
>>>>> sectors on each track. I'm not able to reproduce this in VICE or YaPe.
>>>>> I
>>>>> don't have a real 1551 to check how reliable this is either, but
>>>>> indeed
>>>>> it works on emulated Pi1551.
>>>> 
>>>> and how does it configure the clock divider to allow 21 sectors on the
>>>> smaller tracks?
>>> 
>>> The density config is independent from the track. The problem here is that
>>> the faster/more dense setting becomes less reliable on the inner tracks
>>> (which is why it exists in the first place)
>> 
>> let me change slightly the question: how does the firmware pack 21
>> sectors on the smaller tracks without running out of space?
>> With standard shugart/IBM controllers (so fixed clock rate independent
>> from the track number), they are forced to use the lowest amount of
>> sectors that fit in the smallest track in less than one rotation
>> period.
> 
> Yes. And it is the same for every track.
> 
>> So I'd expect on a 1541 format that 21 sectors do overrun the track
>> length well before reaching track 35.
>> If you have a flux image of such a formatted floppy, I'd like to see it.
> 
> No idea what you are asking. Writing a track works exactly the same, no matter
> if Track 1 or Track 35. If you can write 21 sectors to one track, using a
> certain density, you can do the same on every other track.

...maybe, if you could get the controller to squirt the bits out fast enough (you can't), or if you could read them back fast enough (you really can't), or if it didn't exceed the media's design limits on flux transitions per unit length (it does).

Working in simulation means nothing to actual physics.