Fluxengine crash when writing a 40 track Commodore1541 disk in a 80 track drive

[wybren1971]

Hallo @davidgiven ,

today i was trying to write a 40track disk in a 80 track drive See also: #257 @hpingel. I specified the following command: 'write commodore1541 -i "/data/commodore1541.d64" --input.image.img.physical_offset=1 --input.image.img.physical_step=2 -d drive:0 -c 0-79 -h 0" fluxengine crashed with the following message: /bin/bash: line 1: 5604 Segmentation fault (core dumped) "/home/wybren/Documents/given/fluxengine/fluxengine" write commodore1541 -i "/data/commodore1541.d64" --input.image.img.physical_offset=1 --input.image.img.physical_step=2 -d drive:0 -c 0-79 -h 0

How can i specify in protoconfig that one logical track does not map directly onto one physical track? with the previous version i could change this with :o=1:t=2: o specifies the offset, and t specifies the step. So, with this format, cylinder 1 in the image will be written to track 3 on the disk. I thought that --input.image.img.physical_offset=1 --input.image.img.physical_step=2 would do the same and write a 40 track commodore1541 disk in an 80 track drive. Could you please help?

thanks

Wybren

[davidgiven]

Well, that's not good. That should have worked. The 40-track stuff got rather mangled in the config rewrite; I've been hoping to come up with a cleaner way to do it (but haven't).

So, I've fixed the crash and the logical:physical mapping, so this ought to work now. Could you try the version from the c64 branch, please? Also, your command is wrong; by using --input.image.img you're resetting the image type from D64 back to IMG, so it won't be read correctly. (There could plausibly be a warning there.) You just need this:

./fluxengine write commodore1541 -i image.d64 -d drive:0

[wybren1971]

And this command works for both a 80 track drive and a 40 track drive? i downloaded the branch, my fluxenginemachine is compiling....

[wybren1971]

I tested this branch and it works fine!! on a 80 track drive. (easyfix EFD-120) What i tested: i used attached .d64 file (which i made reading from a old disk with the 80 track drive) commodore1541.zip then i wrote the file back to the same disk (with the 80 track drive) and that disk loaded in my old 1541II drive and commodore 64. then i took a new floppy (Nashua MD2D Double density) and put that in my old 1541II drive. i got an error because the floppy was not formatted. I put the unformatted floppy in the 80 track drive and wrote the .d64 file back to it. i put the floppy in the old 1541II drive and the disk loaded fine, i could play the game. So it seems to work! @hpingel try the c64 branch and see if it works for you. Anything else you @davidgiven would like me to test. I'm gonna put my 40 track disk back and test if the write still works with a 40track disk.

update: reading the disk written with the 80 track drive goes fine with my 40 track drive, but writing an image with my 40 track drive goes wrong now, because fluxengine wrongly assumes that i have an 80 track drive attached. even if i specify the -c 0-39 -h 0 So this doesnt go well.. @davidgiven did i do something wrong? can i specify that i have a 40 track drive so it doesn't skip a track each time when writing to commodore1541 disk?

[hpingel]

Wow! I will test that as soon as real life allows!

[hpingel]

My problem is at the moment that the first and the last sector of each track (sector 0 and sector 17 to 14 depending on the track) are corrupt (bad checksum) when I try to read a disk using Fluxengine right after I have written it. This problem persists after updating to the latest cydsn-Fluxengine-Firmware with both of my 5.25" 80 track PC floppy drives (TEAC and EPSON).

To be fair, I have never written any images back to 5.25" floppy disk with Fluxengine before so there could be the same issue coming up. I have to test that.

On the good side, opening the Fluxengine-read d64 file in Dirmaster (a Disk image "manipulation" tool) I can see that the directory content is 75% uncorrupted. So at least Fluxengine is able to read most of the sectors again. In the Commodore 1541 II drive I still have no luck in persuading it to read the directory.

Fluxengine output looks like this when reading the floppy content directly after writing it:

I removed a second 3.5" disk drive from the ribbon cable to check if it influences the result but apparently not. I could still test with Greaseweazle F1 if this changes something.

But I believe there might be some trick to change the timing so that first and last sector are not overwriting each other?

EDIT: I used my own d64 image files for these tests, so I didn't use the archive provided by @wybren1971.

[hpingel]

### SUCCESS!!!!!!!

With my TEAC FD-55 GFR I looked up the documentation of the jumpers on the floppy drive PCB (https://retrocmp.de/fdd/teac/TEAC_FD-55_Jumper-settings.pdf) and I put a jumper on position "I" where there was no jumper so far. This allows the floppy drive to either rotate with 360rpm or 300rpm depending on the disk type it is able to detect (I hope this description is correct).

So if I put in a Double Density disk (MD2-DD) I can successfully write a D64 image to the disk as the drive then rotates at 300rpm I guess and I can read it successfully in both Fluxengine and a real 1541!

This is the magic of the weekend for me! Thank you both for your work on this!

[davidgiven]

That's fantastic --- I genuinely didn't know if that track erasure trick would work! Just to check, can you try formatting a disk with any 80 track format, and then writing the C64 disk to it and making sure it still works in a real C64? (Just to make sure that the track erase stuff actually works.)

The C64 encoder does assume that each track is 200ms long, which corresponds to a 300rpm disk. This could easily be made configurable.

[hpingel]

It's getting even better: I thought: OK, test another written disk with a full-blown C64 demo that fills a whole disk. If any data is corrupt, the demo will crash. So I went over to csdb.dk where all the demos are and I looked at the toplist just to download something. A brand new Guppdata demo caught my eye - released today! Oh, perfect, I thought - and it even fits on one disk side.

What demo did I pick there? "Freespin" - The most revolutionary demo of probably all times... https://csdb.dk/release/?id=205500 http://www.quiss.org/freespin/

And Fluxengine wrote it to my disk. And here it runs on my C64 - sadly without the recommended monitor cable hack. The microphone is on the floppy drive for a reason!

https://youtu.be/EtgD7a_ezJ4

[wybren1971]

Great to hear @hpingel And the demo is amazing... what they can do with such limited resources!. i'm just happy that i could contribute something to this amazing piece of software. So all that is left is that writing a .d64 file with a 40 track drive doesn't work. --output.image.img.physical_offset=1 --output.image.img.physical_step=2 doesnt help either. @davidgiven what needs to be done in the fluxengine code to specify a 40 track drive and that it writes accordingly. I think this issue can be closed with the merge of c64 branch. @davidgiven i have two 40 track 5.25" drives. I'm happy to donate one to you for you're great work with this piece of software. Do you want one? (to test the 40 track stuff) and where can i send it?

greetings Wybren

[davidgiven]

Ooh, I'd love one! But depending on where you are it might not be worth posting --- please email me directly at dg@cowlark.com?

Re 40 track drives: that support got broken as part of the protobuf change, as I've had complaints that it's weird and was rethinking it. But I reckon that it's actually the least confusing way to handle 40 track drives so I'll put it back in.

Thanks very much for testing this!

[wybren1971]

No problem. please have a look at my pullrequest #291. i hope i used the protobuf correctly. maybe that is an option. by default 80 track drives work. just when specified forty_track_drive=true will things change.

see my mail for the 40 track drive.

thanks

[hpingel]

Just for the record: My EPSON SD-680L also writes D64 fine once I changed the jumper settings for the RPM so that it allows 300rpm.

I want to work on a test scenario where I can write D64 with Fluxengine and afterwards read the written disk with XUM1541 (OpenCBM + real 1541 floppy) and compare the image files to check if they are the same. This may take some time and so far the written disks seem to work fine for me so I don't really feel an urgent need to get this test scenario up ASAP.

The other thing, fill a disk with 80 tracks first and then go over it with a D64 - I still need to find any 80 track image to do this. I don't have one I believe so I have to look somewhere for one.