#1926 something weird in 1541 writing...

[Zibri]

this code, should write a tracck filled with FF and TWO #$5A

JSR $FDA3

LDA #$5A  
CLV
BVC *     ; this writes another FF
STA $1C01
CLV
BVC *     ; here one #$5A had been written
STA $1C01
CLV
BVC *     ; here another #$5A had been written

LDA #$EE
STA $1C0C

LDY #$00 
STY $1C03

but on the G64, I don't see all FF and 2 5A as they should.
I see one and a half bytes,

On u2plus, the same code generates all FF and two 5A...
I don't know who is wrong :D
But in the U2plus g64 I can clearly see all FF and two 5A.
On vice, I don't.

If you don't want to run that code, just run this and press F1:
https://github.com/Zibri/C64-1541-Speed-Test/raw/master/rpm.prg

Then press space and press F7 to exit.

On track 36 at density 00 (32 cycles per byte) there should be TWO #$5A in track 36.

[Daniel Kahlin]

There could be a delay before the data is written out such that it gets cut off when you turn off write mode. What does this do on a real 1541?

[Ingo Korb]

If I remember the 1541's circuit correctly, the overflow bit indicates that the data from $1c01 has been copied into the parallel-to-serial shifter, so you can change the content of $1c01 after that without losing your previous byte - but that means that the data you last wrote to $1c01 is now being written to the disk, so if you switch from write mode to read mode, your byte will be cut off.

If you have a real 1541 and a logic analyzer or digital oscilloscope you should be able to verify this result on real hardware - comparing with another emulation isn't useful here because it is not clear which of the two is correct.

[Zibri]

if you check the program in the first post.. I wait that the last FF is written
then I wait the first 5A is written
then I wait the second 5A is written
then i disable writing.
so ** TWO** 5A must be written..

[Ingo Korb]

Yes, I read your code. You wait until the last $FF has started writing, then you queue up $5a for writing, wait until it starts writing, then queue up another $5a for writing, wait until it starts writing and then immediately switch to read mode, which - as said before - stops writing in the middle of the byte.

If the overflow flag would work the way you think it does, i.e. if it would indicate that the last byte sent to $1c01 is fully written, writing to the disk would require a much more precise timing because you would have to submit another byte ASAP after the overflow flag is set because the disk keeps on rotating and any delay would create a gap between bytes. Instead, Commodore effectively built a 1 byte deep buffer into the drive electronics, the write shifter will take whatever is on $1c01 when the next byte is needed, start writing it and signal that this buffer is now free again by setting the overflow flag. This relaxes the required timing a lot, you only need to make sure that you have submitted another byte to $1c01 before the current one has finished writing - but if you care about the value of your final byte, you need to wait for one extra overflow before turning off writes to make sure that you don't cut it off.

I haven't looked at the 1541U sources, but I suspect that Gideon feeds the $1c01 output directly into the data buffer that lands into the G64 file because the data appears to be byte-aligned. This is simple to implement, but doesn't exactly match reality because sync marks are not required to end on byte boundaries. With such a flawed emulation it is not surprising that partially-written bytes are not working either because they would require special handling.

[Daniel Kahlin]

The easiest way to check this is if you write a test program that writes the pattern to disk, then reads then pattern back and displays what it read.

You might run into problems with the trailing sync when reading on a 1541. If so you could consider making the trailing part something else than $ff, perhaps $fe.

Note that vice is aiming to replicate the behavior of an actual 1541 so only tests on the real hardware is relevant here.

[Zibri]

the test program is my speed test! is exactly what it does.
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm.prg

Please issue: poke 186,0 before running the program.
The press F1.
Track 36 will be created with all syncs and 2 5A inside.
This works on real hardware too.

I made a second version that does not trigger the bug:
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpmt.prg

This because it writes 3 bytes and in this way it does not trigger U2+ and vice bugs.

[Daniel Kahlin]

which hardware was it tested on, i.e which 1541 variant?

Also, I started rpm.prg in x64sc and I get no indication of faults, what do you mean the bug is?

[gpz]

This program is not useful as a test program. As said, the test should write the pattern, read it back, and display the data that was read. No more no less. Only then we can verify what it actually does on the real hardware, and see if there is a bug in VICE.
Oh and, source for the program would be preferred - so we can modify it for the testbench.

[Zibri]

[Daniel Kahlin]

So unless a there is a way to reproduce this, I guess there is nothing to fix?

[gpz]

To say it again: We need a test program that writes a pattern like the one above, reads it back, and displays the result. Because that is the only way to actually confirm the right behaviour - and we are not basing any patches in the floppy code on wild speculations.