#1928 D64 density incorrectly managed.

[Zibri]

A d64 is a representation of a standard disk.
As such, since the d64 does not include densities, it should report normal densitities (the default).

It does not.
I made my own density scan and it returns density 2.

I also found another program that scans for densities and works perfectly on real hardware.
On D64 it reports DENSITY 2 as mine does.

The program is here:
https://csdb.dk/release/?id=171252

Use a "filled" D64... and you will get all "2"
Use a G64 and you will get the right densities.

Since both d64 and g64 internally are represented as "g64" (binary GCR), perhaps you forgot to set something...
It should be easy to correct.

[Zibri]

on the u2/u2+ this is handled correctly and there is no difference in the output if ran from a D64 or a G64...

[Zibri]

Update: I found the solution:
in src/drive/rotation.c

just execute always rotation_1541_gcr_cycle(dptr);

and it works everything also with D64.

if (dptr->complicated_image_loaded) {
    /* stuff that needs complex and slow emulation */
    if (dptr->P64_image_loaded) {
        rotation_1541_p64_cycle(dptr);
    } else {
        rotation_1541_gcr_cycle(dptr);
    }
} else {
    rotation_1541_simple(dptr);
}

becomes a single line:

        rotation_1541_p64_cycle(dptr);

and the routine rotation_1541_simple can be deleted.

[Zibri]

correction:

this is how it should be:

if (dptr->P64_image_loaded) {
rotation_1541_p64_cycle(dptr);
} else {
rotation_1541_gcr_cycle(dptr);
}

without the "simple" routine.

[gpz]

I wonder what those programs actually do, because VICE completely ignores the densities in an Image (also for G64) and always provides clean data no matter what.
Again, a proper test program is needed.

[Zibri]

please stop moderating my messages.. it makes it difficult for other people...
anyway,
I made the patch I wrote in the previous comments and it works.
there is NO test needed, the routine rotation_1541_simple(dptr); is just to save cpu time but it breaks compatibility.
Also:
it's not true that vice ignores densities. And these programs (mine and the other), just read a number of bytes using bvc/clv and then calculates the time.
Trust me... do this test:
in vice source:
sed -i "s/ rotation_1541_simple(dptr);/ rotation_1541_gcr_cycle(dptr);/" src/drive/rotation.c

and you will see that the program I linked (which anyway has problems on vice) will show the right densities.
If instead you use the rotation_1541_simple routine, all densities are "2" (also in my own program).

About G64 and D64, since a track is round, the track lenght determines the density somehow in vice... I don't know the details.. I just know that without rotation_1541_simple, everything works also on d64.
In my own version of vice I already implemented it.
and I am using it right now.
All densities are reported correctly by my program and the krackerjack program I linked.

[Zibri]

[gpz]

To clarify: The test program needs to measure whatever it measures, and then show the actual data it measured, not whatever conclusion it draws from the data.

[Zibri]