Converting SCP to G64 skips half-tracks

[Dan-Gahlinger]

I have quite a few SCP files which all have half-tracks, but whenever I use g64conv it always skips over them and only converts the whole tracks, leaving out half the data.

I can't find any option or method to get g64conv to do the half-tracks the log shows the raw track counting 0,2,4,6,8 etc for track 1,2,3,4... etc out to raw track 78 for track 40

but never does the half tracks. How do I get it to do the half-tracks?

[markusC64]

SCP Raw track numbers are a little different as you might think: Even numbered tracks are from the top side, odd numbered tracks are from the back side. The default is to convert only the 1st side. Use option scpside to select side.

If the scp file contains around 40 tracks or less, they are considered to be full tracks. If there are more tracks (usually >= 70 tracks are found), they are considered being half tracks.

That's because tracks are saved in that order in scp files - track 0 from top side, track 0 from back side, track 1 from top side, track 1 from back side and so on. And the track table contains a table much like a C array of pointers to track data - being the raw track number the index.

Anyway, you can convert to textual representation and examize what tracks have been decoded.

[Dan-Gahlinger]

Reading the result G64 shows no half tracks :(

Reading the text output there are no half tracks

This is a 1541 so it's only 1 side really. How do I ensure it's converting everything it needs?

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Wednesday, December 15, 2021 12:35:57 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

SCP Raw track numbers are a little different as you might think: Even numbered tracks are from the top side, odd numbered tracks are from the back side. The default is to convert only the 1st side. Use option scpside to select side.

If the scp file contains around 40 tracks or less, they are considered to be full tracks. If there are more tracks (usually >= 70 tracks are found), they are considered being half tracks.

That's because tracks are saved in that order in scp files - track 0 from top side, track 0 from back side, track 1 from top side, track 1 from back side and so on. And the track table contains a table much like a C array of pointers to track data - being the raw track number the index.

Anyway, you can convert to textual representation and examize what tracks have been decoded.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-995013182, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULY4KT2FDI7WUECJHNLURDGX3ANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[markusC64]

Well, in that case I need a sample SCP file to analyze. With my SCP files it is working.

But SCP files are often created in a non standard way, so every surprise is possible...

[Dan-Gahlinger]

What I ended up doing is making a blank formatted disk, creating the SCP from that with half tracks, and attempting to use g64conv on that. then I'll open the result g64 and check, and find no half tracks.

The next challenge I have is with the latest nibwrite (tried all versions) and I've had it say "image contains half tracks" and then not write them, skips right over them, even with -h there.

So I have two problems, getting half tracks into the g64 and then being able to write it properly.

I just tested with just used perl g64conv.pl blank_disk.scp blank_disk.g64

I zipped it down to 4 megs, but it was too big to attach, soo...

https://zerofusion.com/cbmstuff/g64conv/blank_disk.scp (or you can get the .zip too)

---

From: markusC64 @.> Sent: December 15, 2021 1:04 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Well, in that case I need a sample SCP file to analyze. With my SCP files it is working.

But SCP files are often created in a non standard way, so every surprise is possible...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-995035336, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL2F25PZ6KCKNNHBPALURDKCTANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[markusC64]

I have checked your .scp file with a hex editor. How did you create that? I (or another reader) might know that software.

I find it does not contain half tracks. See byte $06 for start track: 00. And byte $07 for end track: $44. Within .scp tracks are numbered as i describes above, so track number $44 is track $22=34 starting from zero. So it is track 35.

If there were half tracks, the end track would have to be two times the value I have found.

But the .scp file contains both sides, because byte $0a is $00, which means both sides.

Here is a specification of the .scp file format: https://www.cbmstuff.com/downloads/scp/scp_image_specs.txt

[markusC64]

empty.7z.zip

Here is an example of an scp file with half tracks. Please remove extension .zip, so you have a .7z file.

[Dan-Gahlinger]

100% guaranteed it has half tracks. I'm attaching screenshots, and I'm attaching a G64 which SCP makes from the SCP file I gave you.

I took screenshots of the scp, and then of the G64 it creates, both showing half tracks.

I'm using SCP v2.40 from cbmstuff for this, it has to comply with his standard, he created it 😉

The G64 that SCP creates from the scp file and the g64 which your tool creates from the same scp are vastly different.

I find his conversion doesn't work well, your tool is far superior, except that I can't get half tracks working with yours. I hope that by fixing this you don't "break" your tool in making it exactly like his. 🙁

---

From: markusC64 @.> Sent: December 16, 2021 3:31 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

I have checked your .scp file with a hex editor. How did you create that? I (or another reader) might know that software.

I find it does not contain half tracks. See byte $06 for start track: 00. And byte $07 for end track: $44. Within .scp tracks are numbered as i describes above, so track number $44 is track $22=34 starting from zero. So it is track 35.

If there were half tracks, the end track would have to be two times the value I have found.

But the .scp file contains both sides, because byte $0a is $00, which means both sides.

Here is a specification of the .scp file format: https://www.cbmstuff.com/downloads/scp/scp_image_specs.txt

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-996172669, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL4JS6Z46FBUXL6A3RDURJEBXANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

that is one messed up image. track 18 isn't even standard.

I just sent you screenshots of my scp file - made using SCP, and the resulting g64 which SCP creates from that.

When I first tried to use SCP to convert the file you just sent, it failed, So i reduced the end track to 35 and it seems ok.

Maybe what SCP does to create the SCP from your file will help you so I'm attaching it.

the way SCP creates G64s and the way your tool makes them seems radically different. and again, yours is best - exception half tracks

---

From: markusC64 @.> Sent: December 16, 2021 3:47 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

empty.7z.ziphttps://github.com/markusC64/g64conv/files/7730314/empty.7z.zip

Here is an example of an scp file with half tracks. Please remove extension .zip, so you have a .7z file.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-996182147, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL6F7F6OIYRCI4W7JNLURJF5DANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

that is one messed up image. track 18 isn't even standard.

My sample .scp is from a double sided 1571 standard disk. So yes, there a minor differences between that image and a standard 1541 image.

[markusC64]

Okay, I actually have an original SuperCard Pro, so let me check creating images with that device.

But I remember that some software versions had bugs...

[Dan-Gahlinger]

As I said, don't rely too heavily on SCP, most of the time it doesn't produce working G64's, at least for me. Some images it's just fine, but others, never works.

I've been using g64conv almost exclusively except a few rare cases.

There are even times when scp generated g64 directory fails to load, even though it looks ok in dirmaster or vice preview. but load "$",8 fails.

I have had a handful of situations where g64conv will have a divide by zero error trying to convert an scp to g64 These have all been with scp's that have only 1 or 2 revolutions (splice mode), those with 5 revs seem ok.

---

From: markusC64 @.> Sent: December 17, 2021 2:29 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Okay, I actually have an original SuperCard Pro, so let me check creating images with that device.

But I remember that some software versions had bugs...

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-996497901, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL3JEIB4BISWCQVCA6DURLRFTANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

I don't know if this is useful at all, but I just tried another scp comparing what SCP generates and what g64conv generates:

-rw-rw-rw- 1 dan users 558342 Dec 17 09:32 rot1.g64 -rw-r--r-- 1 dan users 317884 Dec 17 09:40 rot2.g64 -rw-rw-rw- 1 dan users 20929996 Dec 17 09:32 rot.scp

rot1.g64 is what SCP generated, and rot2.g64 is what g64conv generated. the SCP generated file is almost double the size, I suspect because of half tracks.

---

From: markusC64 @.> Sent: December 17, 2021 2:29 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Okay, I actually have an original SuperCard Pro, so let me check creating images with that device.

But I remember that some software versions had bugs...

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-996497901, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL3JEIB4BISWCQVCA6DURLRFTANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

Yes. I see.

In case there are read erros on the converted image, try adding "v5000" parameter. Not sure about which value is best, but a few thousands should do. Because .scp has a larger timing resulution, the range where the endpint of the track has to be searched has to be larger compared to kryoflux (the default values are fine with kryoflux).

From the file sizes, I guess that the g64 image from cbmstuff's software contains half tracks. Fine. For the scp image I am not sure... Because of other possible parameters, you cannot tell from file size alone.

But I found more software that tells me that we do not have half tracks in the image you posted...

[Dan-Gahlinger]

How is that possible when SCP analyzer/editor clearly sows half tracks, and you can even see the data?

ddr64 half track support doesn't really work. so if you can let me know the other tool you tried.

thanks

---

From: markusC64 @.> Sent: December 17, 2021 10:00 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Yes. I see.

In case there are read erros on the converted image, try adding "v5000" parameter. Not sure about which value is best, but a few thousands should do. Because .scp has a larger timing resulution, the range where the endpint of the track has to be searched has to be larger compared to kryoflux (the default values are fine with kryoflux).

From the file sizes, I guess that the g64 image from cbmstuff's software contains half tracks. Fine. For the scp image I am not sure... Because of other possible parameters, you cannot tell from file size alone.

But I found more software that tells me that we do not have half tracks in the image you posted...

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-996787878, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL4O3ASZ27FKBG5Z3JTURNGCLANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

I used code from greaseweazle to check it.

Well, I investigated and found that g64conv has problems with the combination single sided scp image with half tracks.

As an immediately workaround I suggest using the settings "IBM 360k" resp. "IBM 720k" for readings disks with the SuperCard Pro Software.

I'll investiagte what is going wrong and fix it.

[Dan-Gahlinger]

Sorry if this is long...

Greaseweazle has NO support for half tracks!

I confirmed this with the author ages ago.

Reading disks it's incapable of handling half tracks even if you reduce the step size to minimal.

It is physically impossible to read half tracks with greaseweazle

Unfortunately.

Load up SCP editor/analyzer and you'll see the half tracks are there.

For the most part half tracks are lower priority, it would just be good to get them to work.

Bte your option suggestions, these are images from c64 1541 drive. It just seems odd to use IBM options but I'll give it a try.

My more immediate concern is other bugs, the divide by zero I get on certain images.

Rare error: unable to read directory on a image thst should be perfectly fine

Rarest: displays just track numbers, does whole convert in mere seconds but doesn't produce anything and not showing zones, speeds, positions etc

BTW there's a tool called ddr64 (private), that ones half tracks support is also broken, I submitted a bug there but who knows.

For the above bugs there's no half tracks involved and I could only share the scp privately.

Here one last one for you. No half tracks. I dump the scp to text. I convert the scp to g64 The g64 doesn't work due to copy protection. I replace the problem track of the g64 with the text dump of the track of the scp. And it works. At least for the copy protection on that track.

Curiosity questions:

Will you consider adding support to convert to/from d64 or nib formats? I was thinking the text file for those but...

Nibconv can only go in one direction

BTW thanks and it's a really great tool!

Dan

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Saturday, December 18, 2021 5:52:08 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

I used code from greaseweazle to check it.

Well, I investigated and found that g64conv has problems with the combination single sided scp image with half tracks.

As an immediately workaround I suggest using the settings "IBM 360k" resp. "IBM 720k" for readings disks with the SuperCard Pro Software.

I'll investiagte what is going wrong and fix it.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997184792, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULYI7EI5ZRASLZUG4JLURRRVRANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

Greaseweazle has NO support for half tracks! I confirmed this with the author ages ago.

Actually GW does support half tracks. I have seen many .scp files created with recent GW software that contains half tracks.

Bte your option suggestions, these are images from c64 1541 drive. It just seems odd to use IBM options but I'll give it a try.

It's quite odd that you have to select a format when no decoding is done - the flux is stored inside the scp file as it is on disc.

My more immediate concern is other bugs, the divide by zero I get on certain images.

Quite probable, that images has less rotations then it has to. An .scp image has to store at least 3 rotations in order to be processed with g64conv. Because I need a rotation where I have flux values before and after - the hardware does not give a perfect fit of the rotation, so it needs to be optimized.

Anyway, I have created images from the test demo disk with different settings. And I think I should receive greaseweazle images - just to be sure GW will not be broken by changes I must make.

BTW: g64 to d64 and back is working... the same with d71/g71 pair.

I hope to code an scp info tool soon, which displays information for a given scp so #rotations and so on can be listed. Might help for any analysis.

[Dan-Gahlinger]

When I try d64 I get the error unsupported.

I've never had gw make half tracks and asked the author he said no. But that was probably 2-3 years ago

I didn't know about 3 rotations. Damn. That explains a lot.

The image I shared has to have half tracks though, editor/analyzer can't display data that's not there.

Nibwrite displays image has half tracks. But we've been having problems there too.

I'll try those options

Thanks!

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Saturday, December 18, 2021 1:05:55 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Greaseweazle has NO support for half tracks! I confirmed this with the author ages ago.

Actually GW does support half tracks. I have seen many .scp files created with recent GW software that contains half tracks.

Bte your option suggestions, these are images from c64 1541 drive. It just seems odd to use IBM options but I'll give it a try.

It's quite odd that you have to select a format when no decoding is done - the flux is stored inside the scp file as it is on disc.

My more immediate concern is other bugs, the divide by zero I get on certain images.

Quite probable, that images has less rotations then it has to. An .scp image has to store at least 3 rotations in order to be processed with g64conv. Because I need a rotation where I have flux values before and after - the hardware does not give a perfect fit of the rotation, so it needs to be optimized.

Anyway, I have created images from the test demo disk with different settings. And I think I should receive greaseweazle images - just to be sure GW will not be broken by changes I must make.

BTW: g64 to d64 and back is working... the same with d71/g71 pair.

I hope to code an scp info tool soon, which displays information for a given scp so #rotations and so on can be listed. Might help for any analysis.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997240109, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL5GLU5C3IQDPDZSPY3URTEQHANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

Turns out I was using an old version of your utility.

I've nos got the one from today I think V3.20

BTW curiosity question.

I have an scp file I can write to a real disk and it works perfectly

But converting thst scp to g64 then writing that to real floppy fails to work, every time.

I'll try this latest version and see how that goes, I'll also grab the latest greaseweazle code and try it.

Ddr64 didn't work.

An scp info would be great.

BTW I looked at a recent text file dump your util made from an scp file and I see track 10.5 ! So half tracks. Yay

I'll also see if GW can successfully write this wonky image.

Dan

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Dan G @.> Sent: Saturday, December 18, 2021 1:14:19 PM To: markusC64/g64conv @.>; markusC64/g64conv @.> Cc: Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

When I try d64 I get the error unsupported.

I've never had gw make half tracks and asked the author he said no. But that was probably 2-3 years ago

I didn't know about 3 rotations. Damn. That explains a lot.

The image I shared has to have half tracks though, editor/analyzer can't display data that's not there.

Nibwrite displays image has half tracks. But we've been having problems there too.

I'll try those options

Thanks!

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Saturday, December 18, 2021 1:05:55 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Greaseweazle has NO support for half tracks! I confirmed this with the author ages ago.

Actually GW does support half tracks. I have seen many .scp files created with recent GW software that contains half tracks.

Bte your option suggestions, these are images from c64 1541 drive. It just seems odd to use IBM options but I'll give it a try.

It's quite odd that you have to select a format when no decoding is done - the flux is stored inside the scp file as it is on disc.

My more immediate concern is other bugs, the divide by zero I get on certain images.

Quite probable, that images has less rotations then it has to. An .scp image has to store at least 3 rotations in order to be processed with g64conv. Because I need a rotation where I have flux values before and after - the hardware does not give a perfect fit of the rotation, so it needs to be optimized.

Anyway, I have created images from the test demo disk with different settings. And I think I should receive greaseweazle images - just to be sure GW will not be broken by changes I must make.

BTW: g64 to d64 and back is working... the same with d71/g71 pair.

I hope to code an scp info tool soon, which displays information for a given scp so #rotations and so on can be listed. Might help for any analysis.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997240109, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL5GLU5C3IQDPDZSPY3URTEQHANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

Ok, I feel stupid, I can't figure out how to specify those settings ("IBM 360k" resp. "IBM 720k") ? I tried googling it with no luck, read through the templates, didn't see it there, and no reference to IBM or 720k in g64conv.pl either

---

From: markusC64 @.> Sent: December 18, 2021 1:05 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Greaseweazle has NO support for half tracks! I confirmed this with the author ages ago.

Actually GW does support half tracks. I have seen many .scp files created with recent GW software that contains half tracks.

Bte your option suggestions, these are images from c64 1541 drive. It just seems odd to use IBM options but I'll give it a try.

It's quite odd that you have to select a format when no decoding is done - the flux is stored inside the scp file as it is on disc.

My more immediate concern is other bugs, the divide by zero I get on certain images.

Quite probable, that images has less rotations then it has to. An .scp image has to store at least 3 rotations in order to be processed with g64conv. Because I need a rotation where I have flux values before and after - the hardware does not give a perfect fit of the rotation, so it needs to be optimized.

Anyway, I have created images from the test demo disk with different settings. And I think I should receive greaseweazle images - just to be sure GW will not be broken by changes I must make.

BTW: g64 to d64 and back is working... the same with d71/g71 pair.

I hope to code an scp info tool soon, which displays information for a given scp so #rotations and so on can be listed. Might help for any analysis.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997240109, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL5GLU5C3IQDPDZSPY3URTEQHANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

Well, the "IBM 720k" setting is in the SuperCard Pro Software you used to create images from real disks.

And yes, I know it's a workaround - current g64conv misinterprets single sided scp image files, so creating double sided scp image files helps, but not for existing scp image files.

[markusC64]

I have an scp file I can write to a real disk and it works perfectly But converting thst scp to g64 then writing that to real floppy fails to work, every time.

I have observed that, too. scp files created using the same floppy drive work, scp files created with other floppy drives do not work quite often. And converted scp files do not work, either.

I found that the difference is the RPM value of the drives is the problem. Without options, an RPM of IIRC 300 (or was it 360) is generated.

You can specify a different RPM value at conversion:

g64conv.pl foo.g64 foo.scp 360.01

or even

g64conv.pl foo.g64 foo.scp 6666666

where this number is the track duration in clocks of the SuperCard Pro (25ns). With the right clock duration it will work for double sided disks. For single sided disks, probably the same problem has to be fixed we observed above.

[Dan-Gahlinger]

Even on the same physical drive it fails.

I was able take 720k and 360k scp and convert to g64 but I fear writing them back as g64 will still fail.

I believe it assumes 360 rpm and it should be 300 so I'll give thst a shot.

The ability to convert an IBM 720k scp to a 1541 g64 is just scary :) but good.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Sunday, December 19, 2021 4:45:02 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

I have an scp file I can write to a real disk and it works perfectly But converting thst scp to g64 then writing that to real floppy fails to work, every time.

I have observed that, too. scp files created using the same floppy drive work, scp files created with other floppy drives do not work quite often. And converted scp files do not work, either.

I found that the difference is the RPM value of the drives is the problem. Without options, an RPM of IIRC 300 (or was it 360) is generated.

You can specify a different RPM value at conversion:

g64conv.pl foo.g64 foo.scp 360.01

or even

g64conv.pl foo.g64 foo.scp 6666666

where this number is the track duration in clocks of the SuperCard Pro (25ns). With the right clock duration it will work for double sided disks. For single sided disks, probably the same problem has to be fixed we observed above.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997358788, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZKGQZFLMNIJV5U7DLURWSR5ANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

For commodore 1540, 1541, 1570 and 1571 I agree they have 300 rpm. And so do PC Double Density drives. But 5,25" HD Drives have 360 RPM. So if you use such one to write an image, you need 360 RPM images unless the writing software silently adjusts timing information from the image.

Yes, when converting images with g64conv, precise information about the RPM is lost. On purpose because that is a parameter of the drive used and noz a parameter of the physical disk.

[Dan-Gahlinger]

Ok to be clear

If the scp was created on a HD drive I should be using 360 ram in the conversion even if the resulting g64 will be written to a real disk using the sane HD drive?

Actually that makes sense.

But then if we write with nibwrite do we then use -c 360 option there?

And maybe you can tell what command line to use with greaseweazle as well to try to write with tge g64 with that as well.

There are very limited ways to write a g64 to a real disk :(

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Sunday, December 19, 2021 7:13:02 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

For commodore 1540, 1541, 1570 and 1571 I agree they have 300 rpm. And so do PC Double Density drives. But 5,25" HD Drives have 360 RPM. So if you use such one to write an image, you need 360 RPM images unless the writing software silently adjusts timing information from the image.

Yes, when converting images with g64conv, precise information about the RPM is lost. On purpose because that is a parameter of the drive used and noz a parameter of the physical disk.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997381791, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL2UNBWPZQADMJNT7ALURXD45ANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

If the scp was created on a HD drive I should be using 360 ram in the conversion even if the resulting g64 will be written to a real disk using the sane HD drive?

Yes.

But then if we write with nibwrite do we then use -c 360 option there?

No. But keep in mind that a 1541/70/71 cannot write every copy protection. And it cannot write half tracks reliable. The latter is the cause that burstnibbler and turbonibbler recommend in their manuals that only the half track with the copy protection is written. (Problem: User must know that track, in realitty he often does not know).

Well, I don't have a greaseweazle, so I cannot help with command lines for that device...

[Dan-Gahlinger]

The current problem image has no half tracks.

Vice 2.4 sps runs the g64 just fine.

Do you know of any other way to write g64 to a real disk?

Scp doesn't support it :(

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Sunday, December 19, 2021 8:03:30 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

If the scp was created on a HD drive I should be using 360 ram in the conversion even if the resulting g64 will be written to a real disk using the sane HD drive?

Yes.

But then if we write with nibwrite do we then use -c 360 option there?

No. But keep in mind that a 1541/70/71 cannot write every copy protection. And it cannot write half tracks reliable. The latter is the cause that burstnibbler and turbonibbler recommend in their manuals that only the half track with the copy protection is written. (Problem: User must know that track, in realitty he often does not know).

Well, I don't have a greaseweazle, so I cannot help with command lines for that device...

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997388416, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL2RL64ONMUO32AZKMLURXJ2FANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

I've confirmed what you said, a 1541 without extra ram will never write this image.

That leaves scp or greaseweazle. Possibly kryoflux if g64conv can do that.

BTW I bet you never thought anyone would use your util for copying protected disks, but I found working with text files much easier!

Is there a hex to gcr converter somewhere?

And also a tool to calculate the gcr checksum? And the bits.

That scp info tool would be great.

BTW confirmed again your v3.2 seems to handle half tracks just fine!

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Dan G @.> Sent: Sunday, December 19, 2021 8:28:33 AM To: markusC64/g64conv @.>; markusC64/g64conv @.> Cc: Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

The current problem image has no half tracks.

Vice 2.4 sps runs the g64 just fine.

Do you know of any other way to write g64 to a real disk?

Scp doesn't support it :(

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Sunday, December 19, 2021 8:03:30 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

If the scp was created on a HD drive I should be using 360 ram in the conversion even if the resulting g64 will be written to a real disk using the sane HD drive?

Yes.

But then if we write with nibwrite do we then use -c 360 option there?

No. But keep in mind that a 1541/70/71 cannot write every copy protection. And it cannot write half tracks reliable. The latter is the cause that burstnibbler and turbonibbler recommend in their manuals that only the half track with the copy protection is written. (Problem: User must know that track, in realitty he often does not know).

Well, I don't have a greaseweazle, so I cannot help with command lines for that device...

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997388416, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL2RL64ONMUO32AZKMLURXJ2FANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

I've confirmed what you said, a 1541 without extra ram will never write this image.

That does not sound reasonable. A parallel cable has no disadvantage in what is writable and what is not writable. But perhaps you can tell the name of the game / program you're trying to write - so I might know more details.

You see, he problem with a 1541 is that data has to be transfered to the floppy as fast as the disk rotates. A parallel cable will do that, but extra RAM which just has to be read will do that too.

Anyway. Kryoflux is quite bad in writing non g64 files. And g64 cannot contain some copy protections (e. g. speed modifications with multiple non standard speeds per track).

Greeseweazle can write them (some [more] time ago I have had a discussion with the author of gw) but may need an embedded hint for the write splice area in the scp file. Currently there is no automatic way to create that.

With SuperCard Pro I am able to write disks back, after converting them to SCP with the exact totation speed of my drive - it's around 360 RPM, but of cause not exactly, no drive is exactly at 360 RPM, there is always a tolerance). The SuperCard Pro has a heuristic to find the write splice area itself. If it finds the right one, you're fine. If it finds the wrong one, I have no idea... Try reading back written images from SuperCard Pro... If you find exactly one error on tracks - and that position is near the position of the index pulse, then the RPM of the SCP used to write back is probably wrong or the wrong write splice area has been used (for si images like GEOS or unprotected disks, the SuperCard Pro Software is using the right Write Splice Area, so it's RPM in that case).

But I learned from this issue that g64conv needs a fix to work witrh the SupetrCard Pro perfectly.

In Summary, writing images back for cases where nibtools fail is not that easy.

[Dan-Gahlinger]

the g64 I created works perfectly in winvice 2.4 SPS

also writing the SCP back to a floppy disk using a PC floppy drive works perfectly.

however, writing the g64 to floppy with nibwrite it fails the copy protection.

I will try g64conv with 360rpm, just as a further check.

This is why I asked about kryoflux, using it to write the g64 to a floppy disk perhaps.

just trying to find options of creating an image that is easily usable.

---

From: markusC64 @.> Sent: December 19, 2021 9:51 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

I've confirmed what you said, a 1541 without extra ram will never write this image.

That does not sound reasonable. A parallel cable has no disadvantage in what is writable and what is not writable. But perhaps you can tell the name of the game / program you're trying to write - so I might know more details.

You see, he problem with a 1541 is that data has to be transfered to the floppy as fast as the disk rotates. A parallel cable will do that, but extra RAM which just has to be read will do that too.

Anyway. Kryoflux is quite bad in writing non g64 files. And g64 cannot contain some copy protections (e. g. speed modifications with multiple non standard speeds per track).

Greeseweazle can write them (some [more] time ago I have had a discussion with the author of gw) but may need an embedded hint for the write splice area in the scp file. Currently there is no automatic way to create that.

With SuperCard Pro I am able to write disks back, after converting them to SCP with the exact totation speed of my drive - it's around 360 RPM, but of cause not exactly, no drive is exactly at 360 RPM, there is always a tolerance). The SuperCard Pro has a heuristic to find the write splice area itself. If it finds the right one, you're fine. If it finds the wrong one, I have no idea... Try reading back written images from SuperCard Pro... If you find exactly one error on tracks - and that position is near the position of the index pulse, then the RPM of the SCP used to write back is probably wrong or the wrong write splice area has been used (for si images like GEOS or unprotected disks, the SuperCard Pro Software is using the right Write Splice Area, so it's RPM in that case).

But I learned from this issue that g64conv needs a fix to work witrh the SupetrCard Pro perfectly.

In Summary, writing images back for cases where nibtools fail is not that easy.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997405276, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL4E46IXQMHEJUHYT23URXWPDANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

I remember of problems with nibtools writing images from flux source...

Anyway, I cannot tell you if a 1541 can write the image you try - I don't know what is contained in the image. Just naming the software might tell me.

[markusC64]

You're invited to try my testest commit from today with some changes in reading scp files. I hope they're better compatible.

Have to adjust creating scp files is well - not yet done.

[Dan-Gahlinger]

I talked to someone else about this, and they've posted their SCP image publically

so you can take a look at it, and maybe we can figure it out.

https://archive.org/download/VG_Datashack_Fast_Copiers/VG%20Datashack%20Super%20Fast%20File%20Copy.splice.HT.r5.t40.%5BSUCCESSFUL.COPY%5D.JBC.scp

Track 11 there is the problem track, it has no sync marks and no headers of any kind. it's one continuous repeating byte "55" I think.

it's one huge long sector - of 7,926 bytes.

Nibwrite fails to write this properly, as we have checked the 1541 can't write that much data it doesn't have the ram, and it has to do it without buffering, which is why drive ram is needed.

Now if nibwrite could use the super card plus (SC+) ram, that'd be different. But I don't see any way around this with a 1541.

You can see the other SCP and g64's that were generated from them here:

https://archive.org/download/VG_Datashack_Fast_Copiers

Dan.

---

From: markusC64 @.> Sent: December 19, 2021 12:27 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

You're invited to try my testest commit from today with some changes in reading scp files. I hope they're better compatible.

Have to adjust creating scp files is well - not yet done.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997429675, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL2KAIAYQHVUA5CKLOLURYIX5ANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

Yes, in order to write 7926 bytes, the drive would have to use non standard timing, even faster than the fastest speed zone 3. But a commodore drive can only write the standard speeds of the speed zones 0, 1, 2 and 3.

[Dan-Gahlinger]

If I write just that track is there a way to get it to work purely through software, like with nibwrite isn't there an option for that?

Or would it require a hardware speed adjustment on the drive itself?

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Monday, December 20, 2021 3:24:57 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Yes, in order to write 7926 bytes, the drive would have to use non standard timing, even faster than the fastest speed zone 3. But a commodore drive can only write the standard speeds of the speed zones 0, 1, 2 and 3.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997700354, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZX55J2AA6XWNUE3LLUR3R5TANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

I'm also trying to figure out how a 1541 with extra ram writes this track properly.

It seems to me then that there might be a way with nibwrite

Could a custom option be added if it's not already there? I seem to recall something like it

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Dan G @.> Sent: Monday, December 20, 2021 10:51:27 AM To: markusC64/g64conv @.>; markusC64/g64conv @.> Cc: Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

If I write just that track is there a way to get it to work purely through software, like with nibwrite isn't there an option for that?

Or would it require a hardware speed adjustment on the drive itself?

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Monday, December 20, 2021 3:24:57 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Yes, in order to write 7926 bytes, the drive would have to use non standard timing, even faster than the fastest speed zone 3. But a commodore drive can only write the standard speeds of the speed zones 0, 1, 2 and 3.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-997700354, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZX55J2AA6XWNUE3LLUR3R5TANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

On forum64.de, we're all sure a 1541 cannot write such tracks without deep hardware modification. Either slow down disk rotation significantly (quite much) - or replace the writing logic by something more flexible.

BTW: Extra RAM will not help.

PS: There might be the possibility that the protection check does not verify everything of the track so that working copies might be possible with a 1541 - I haven't checked the copy protection code at all. Anyway, I don't get the image working in VICE 3.2 at all... Perhaps I should check VICE 3.4.

[Dan-Gahlinger]

It won't work on v3.4 vice.

Only WinVice v2.4 SPS - very specific - works. because that's the only version of vice that does g64 emulation properly.

I downloaded the zip and posted it for convenience... https://zerofusion.com/cbmstuff/WinVICE-2.4a-SPS.zip

the protection check does a byte count, it's really that simple. as long as the # of bytes on the track matches, it passes. It's incredibly simple.

So it remains, how to get so many bytes on one track. Obviously SCP and GW can do it because those use PC drives. But I know that SC+ (with extra ram) has done this on a 1541, somehow. But I'm trying to get someone to confirm it actually works.

We can hopefully verify this by writing the g64 to floppy using nibwrite, then copy only track 11 with SC+ overtop with the whole track copier.

---

From: markusC64 @.> Sent: December 20, 2021 11:56 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

On forum64.de, we're all sure a 1541 cannot write such tracks without deep hardware modification. Either slow down disk rotation significantly (quite much) - or replace the writing logic by something more flexible.

BTW: Extra RAM will not help.

PS: There might be the possibility that the protection check does not verify everything of the track so that working copies might be possible with a 1541 - I haven't checked the copy protection code at all. Anyway, I don't get the image working in VICE 3.2 at all... Perhaps I should check VICE 3.4.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-998103777, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZM6MSW7GEXJWLCJM3UR5N2ZANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

Quote from source...

The v2.4 SPS version is the ONLY version that has the latest fixes for the 1541 emulation. Those fixes are not being pushed to the later versions due to a disagreement with the parties involved.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Dan G @.> Sent: Monday, December 20, 2021 12:35:23 PM To: markusC64/g64conv @.>; markusC64/g64conv @.> Cc: Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

It won't work on v3.4 vice.

Only WinVice v2.4 SPS - very specific - works. because that's the only version of vice that does g64 emulation properly.

I downloaded the zip and posted it for convenience... https://zerofusion.com/cbmstuff/WinVICE-2.4a-SPS.zip

the protection check does a byte count, it's really that simple. as long as the # of bytes on the track matches, it passes. It's incredibly simple.

So it remains, how to get so many bytes on one track. Obviously SCP and GW can do it because those use PC drives. But I know that SC+ (with extra ram) has done this on a 1541, somehow. But I'm trying to get someone to confirm it actually works.

We can hopefully verify this by writing the g64 to floppy using nibwrite, then copy only track 11 with SC+ overtop with the whole track copier.

---

From: markusC64 @.> Sent: December 20, 2021 11:56 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

On forum64.de, we're all sure a 1541 cannot write such tracks without deep hardware modification. Either slow down disk rotation significantly (quite much) - or replace the writing logic by something more flexible.

BTW: Extra RAM will not help.

PS: There might be the possibility that the protection check does not verify everything of the track so that working copies might be possible with a 1541 - I haven't checked the copy protection code at all. Anyway, I don't get the image working in VICE 3.2 at all... Perhaps I should check VICE 3.4.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-998103777, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZM6MSW7GEXJWLCJM3UR5N2ZANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

Thanks. I know that statement - and I know it is several years old and not updated since the release of that VICE version.

So IMO it does not tell us anything about current versions of VICE.

[Dan-Gahlinger]

Question AND Feature Request​

Question: can you explain why your tool needs 3 revolutions (or more), and can't work with just 2? Is there something about two or one?

Feature Request:

I want a feature to replace a single track in one image with a single track from another image. I've been doing this manually by converting both to text, then copying the single track out then the other image I copy all OTHER tracks, then manually paste them back together for the new image but this is REALLY tedious and time consuming,

And right now I have 20 images to do this with, and it's frankly driving me nuts!

Maybe with g64 to text with the range option would be the poor mans version of what I want...

Please and thank you!

---

From: markusC64 @.> Sent: December 21, 2021 3:15 AM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Thanks. I know that statement - and I know it is several years old and not updated since the release of that VICE version.

So IMO it does not tell us anything about current versions of VICE.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-998563110, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL7DZT3FJWZBP4CFU4LUSAZSFANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

Question: can you explain why your tool needs 3 revolutions (or more), and can't work with just 2? Is there something about two or one?

Let's think about that:

(1) We know that a 1541 has no index sensor. Therefore data is not aligned with the index at all. (2) From Observation of Kryoflux Images, SuperCard Pro Images and Greaseweazle Images I found that the stored rotation is not exact - some flux at the end might be missing OR some flux is appended there from the next rotation (3) P64 and G64 need exactly one rotation, nothing less and nothing more (4) From (2) and (3) follows that we need to fix the rotation. This is done by comparing bytes around the estimated end with the beginning. (5) Therefore we need bytes before the beginning of the rotation we use and after the rotation we use - if we use an interval with the end of the rotation as an inner point. (6) With an interval with the end of the rotation as an endpoint or even excluding that endpoint 2 rotations may work - it has not been tested though.

[Dan-Gahlinger]

Wow that explains a lot. Thank you

Any hope on my feature request?

Thanks

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Monday, December 27, 2021 1:36:47 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Question: can you explain why your tool needs 3 revolutions (or more), and can't work with just 2? Is there something about two or one?

Let's think about that:

(1) We know that a 1541 has no index sensor. Therefore data is not aligned with the index at all. (2) From Observation of Kryoflux Images, SuperCard Pro Images and Greaseweazle Images I found that the stored rotation is not exact - some flux at the end might be missing OR some flux is appended there from the next rotation (3) P64 and G64 need exactly one rotation, nothing less and nothing more (4) From (2) and (3) follows that we need to fix the rotation. This is done by comparing bytes around the estimated end with the beginning. (5) Therefore we need bytes before the beginning of the rotation we use and after the rotation we use - if we use an interval with the end of the rotation as an inner point. (6) With an interval with the end of the rotation as an endpoint or even excluding that endpoint 2 rotations may work - it has not been tested though.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1001694199, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL5QZQ3CDG4W424MZTLUTCW37ANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

Maybe with g64 to text with the range option would be the poor mans version of what I want...

Okay, try "g64conv filter". Suppose you'd like to replace track 19 in order to give an example.

g64conv filter src.txt tmp1.txt 1..18.5/0.5 g64conv filter src.txt tmp3.txt 19.5..40/0.5

g64conv filter src2.txt tmp2.txt 19..19

Windows: copy tmp1.txt + tmp2.txt + tmp3.txt tmp.txt Linux: cat tmp[123].txt > tmp.txt

The merging of the image has been done :-)

PS: In my example, the "/0.5" is optional, because the range has a size which is not integer. So half tracks are assumed.

[markusC64]

Or even:

g64conv filter src.txt tmp1.txt 1..18.5/0.5,19.5..40/0.5 g64conv filter src2.txt tmp2.txt 19..19

and then append those two files. :-)

[markusC64]

Any hope on my feature request?

I think I have given you a workaround that allows quite automatic processing

[Dan-Gahlinger]

Yes thank you!

But now I have the obvious feature request...

Can you make it a LOT faster?

I have 30 images at a time to do, just in testing

This whole "rotation" idiocy that Jim's scp images require is totally crazy.

So with the track selection I can now use the text dump to do an automated rotation but its between 18 and 20 per track depending on sync marks.

And I have one scp that depends on mtiple tracks being in proper rotation with each other. So that's 18^2 combinations.

There has to be a better way.

I don't think greaseweazle needs this rotation hassles tho so we will try that

Only thing I can think of for speed is to Nice -19 it :)

Or I can do each one as a daemon & And they'll run simultaneously

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: markusC64 @.> Sent: Monday, December 27, 2021 1:49:16 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Any hope on my feature request?

I think I have given you a workaround that allows quite automatic processing

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1001698062, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZVLAWIMJOR7HQU5WLUTCYKZANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[markusC64]

I know. Hopefully I'll get information from the VICE team about an g64 extension specification. That might have big influence to decide what is best.

I know especially with flux data decoding is slow.

It might also be the case that I have to start a new program for the extended g64 - we will see. It would be quite bad to start now something new and then note: Well, starting from scratch is required. :-(

[Dan-Gahlinger]

Please don't!

Vice's G64 handling is totally borked.

The last version I've tested that works properly is v3.2 nothing after that works.

NONE of the images I've created recently work at all in 3.3,3.4,3.5,or 3.6

Your code is way more reliable than theirs.

Dan.

---

From: markusC64 @.> Sent: December 28, 2021 1:02 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

I know. Hopefully I'll get information from the VICE team about an g64 extension specification. That might have big influence to decide what is best.

I know especially with flux data decoding is slow.

It might also be the case that I have to start a new program for the extended g64 - we will see. It would be quite bad to start now something new and then note: Well, starting from scratch is required. :-(

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002221206, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL7SGHDBCMK7K3GE6BDUTH3RRANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[Dan-Gahlinger]

So a question about greaseweazle and your g64conv code.

GW doesn't have an editor/analyzer like SCP does,

So does GW SCP images need "rotation", like putting sector 0 sync mark in the right place? And if so, how does it do that without the editor/analyzer?

I know GW can write g64 back to floppy, but it seems to depend on your g64conv to convert scp to g64 So again, the whole "rotation" business Jim goes on about

I've done rotation on probably hundreds of SCP images by now using the editor/analyzer in SCP

Inquiring minds want to know... 🙂

---

From: Dan G @.> Sent: December 28, 2021 1:34 PM To: markusC64/g64conv @.>; markusC64/g64conv @.> Cc: Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

Please don't!

Vice's G64 handling is totally borked.

The last version I've tested that works properly is v3.2 nothing after that works.

NONE of the images I've created recently work at all in 3.3,3.4,3.5,or 3.6

Your code is way more reliable than theirs.

Dan.

---

From: markusC64 @.> Sent: December 28, 2021 1:02 PM To: markusC64/g64conv @.> Cc: Dan-Gahlinger @.>; Author @.> Subject: Re: [markusC64/g64conv] Converting SCP to G64 skips half-tracks (Issue #3)

I know. Hopefully I'll get information from the VICE team about an g64 extension specification. That might have big influence to decide what is best.

I know especially with flux data decoding is slow.

It might also be the case that I have to start a new program for the extended g64 - we will see. It would be quite bad to start now something new and then note: Well, starting from scratch is required. :-(

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002221206, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL7SGHDBCMK7K3GE6BDUTH3RRANCNFSM5KCZDHKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>