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]

Can someone please help me to follow - I cannot follow.

Anyway, regarding your post before - we actually need an g64 extension. g64 cannot store mfm data required for 1571.

We do not rotate anything, a rotation is the data read when the disk is rotated once. So a whole track - or something nearby (I wrote above that the rotation of the SCP is not exact).,

What do you mean by rotating a track? Shifting it? Yes some copy proetctions check when moving to another track the data read immediately. So a minor shift might be necessary. But not one that is as large as a complete sector. Anyway, to that I cannot say anything - you should ask someone else.

[markusC64]

BTW: "ad1" is much faster than the default for decong scp (and other flux data), and in many cases good enough.

[Dan-Gahlinger]

You don't need a g64 extension.

The solution already exists.

It is the g71 file.

Notice the g.

Vice, dir master, I think pi1541 and I believe imgcopy all support it

If you need some samples I have some

Don't go changing g64

Dan

---

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

Can someone please help me to follow - I cannot follow.

Anyway, regarding your post before - we actually need an g64 extension. g64 cannot store mfm data required for 1571.

We do not rotate anything, a rotation is the data read when the disk is rotated once. So a whole track - or something nearby (I wrote above that the rotation of the SCP is not exact).,

What do you mean by rotating a track? Shifting it? Yes some copy proetctions check when moving to another track the data read immediately. So a minor shift might be necessary. But not one that is as large as a complete sector. Anyway, to that I cannot say anything - you should ask someone else.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002463247, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZ6NERTA5NPLJYHNS3UTLC6XANCNFSM5KCZDHKQ. 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]

What is "ad1" and how do i use it? Never heard of this

Thanks

---

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

BTW: "ad1" is much faster than the default for decong scp (and other flux data), and in many cases good enough.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002463657, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL3MNQVP3ZWAYESIDBLUTLDCVANCNFSM5KCZDHKQ. 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'm sorry to tell you, but g71 is ponly about two sides of the disk. The additional MFM controller in the 1570/71 is quite a different thing. The 1541 Ultimate II+ / Ultimate 64 contains an g64 extension for that that is somehow limited. It's more of a teledisk image of the track than a real track image. I hope the new format is either backward compatible or have another extension like g64x. So old g64 can be used, too.

Really, in all known version of VICE, the MFM Part of the 1570/71 cannot be used at all.

[markusC64]

And please don't mix MFM with CP/M. Commodore uses GCR for their CP/M Disks. Non-Commodore CP/M Disks are MFM. And PC 5,25" DD disks, which a real 1571 can read.

[Dan-Gahlinger]

But seems like g71 is a better starting point than g64 for this sort of stuff.

To me, g64 isn't meant for this It'd be confusing

I saw rumors of g81 but have never seen one

---

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

I'm sorry to tell you, but g71 is ponly about two sides of the disk. The additional MFM controller in the 1570/71 is quite a different thing. The 1541 Ultimate II+ / Ultimate 64 contains an g64 extension for that that is somehow limited. It's more of a teledisk image of the track than a real track image. I hope the new format is either backward compatible or have another extension like g64x. So old g64 can be used, too.

Really, in all known version of VICE, the MFM Part of the 1570/71 cannot be used at all.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002555750, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL6Y2MBQBNJIZ5QOPMTUTLYIFANCNFSM5KCZDHKQ. 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]

g71 and g64 are mostly the same - track numbers from 43 are used for the back side. And the magic bytes at the begin state they are intended to be used on a 1571. That are all differences, everything else is the same.

So any reference to g64 applies to g71 and the other way round. It does not really make sense to extend g71 but not g64.

[Dan-Gahlinger]

Ok makes sense.

What is "ad1" ?

---

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

g71 and g64 are mostly the same - track numbers from 43 are used for the back side. And the magic bytes at the begin state they are intended to be used on a 1571. That are all differences, everything else is the same.

So any reference to g64 applies to g71 and the other way round. It does not really make sense to extend g71 but not g64.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002563272, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULYUBT6FULDUKEQYWHLUTL2ZFANCNFSM5KCZDHKQ. 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]

"alternative decoder 1", an alternative decoding algorithm for flux gcr data.

g64conv src.scp dst.g64 ad1 g64conv src.scp dst.txt 1 ad1

will both use the faster algorithm. The same applies for any other flux source (Kryoflux or textual P64).

[Dan-Gahlinger]

I'll try it out, if it works with 21 second backup it'll probably be ok for other stuff

BTW what I said before about "rotating" images...

If you image a disk with scp then convert to g64 directly, test image will never work.

The sync mark for sector 0 is never at the beginning of the track in the images So you have to "rotate" the track in SCP editor/analyzer... ie "index" each track one by one at the correct place for all 35 tracks. Otherwise scp images from scp will never work.

I'm going to try GW to create an scp and see because GW has no such editor/analyzer

If it places sector 0 correctly and convert to g64 works then I can stop using scp and use GW

Thank you for all your help!

Please keep updating g64conv and I look forward to the scp info tool

---

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

"alternative decoder 1", an alternative decoding algorithm for flux gcr data.

g64conv src.scp dst.g64 ad1 g64conv src.scp dst.txt 1 ad1

will both use the faster algorithm. The same applies for any other flux source (Kryoflux or textual P64).

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002570882, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL7EVSXMYCHAP6NC4RLUTL5EDANCNFSM5KCZDHKQ. 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]

Marcus, I don't see how GW can possibly work? I'm confused

trying to make an image of a 1541 floppy I most recently tried: gw read --tracks="c=0-79:h=0:h1.off=-8" --revs=5 --retries=10 "image2.scp" which is what some of the instructions say should work with a c64 disk (instructions had h=0,1 for a flippy disk, and since I don't have a flippy disk, I made it just h=0) but SCP reports this to be a CP/M image, and the tracks are all weird.

sure track 1 is track 1, but track 2 is on track 3, and track 3 is on track 5, and track 4 is on track 7, and so forth. it's like the half-tracks have gotten mangled.

ibm.360 format doesn't work at all.

Attempting to use g64conv on any of these scp images produces unusable g64's, well they are mangled going in, so...

How the heck is GW supposed to work or how is g64conv supposed to convert these images?

---

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

Can someone please help me to follow - I cannot follow.

Anyway, regarding your post before - we actually need an g64 extension. g64 cannot store mfm data required for 1571.

We do not rotate anything, a rotation is the data read when the disk is rotated once. So a whole track - or something nearby (I wrote above that the rotation of the SCP is not exact).,

What do you mean by rotating a track? Shifting it? Yes some copy proetctions check when moving to another track the data read immediately. So a minor shift might be necessary. But not one that is as large as a complete sector. Anyway, to that I cannot say anything - you should ask someone else.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1002463247, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWULZ6NERTA5NPLJYHNS3UTLC6XANCNFSM5KCZDHKQ. 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 most recently tried: gw read --tracks="c=0-79:h=0:h1.off=-8" --revs=5 --retries=10 "image2.scp"

Unless you have a (kryoflux) flippy modded drive, you don't want h1.off=-8. If you have, you don't need hat when you're not reading from head 1.

Please try g64conv version 4.2 with

g64conv image2.scp image2.g64 v4000

This version has a fix for the parameter "v4000" to work.

And yes, the SuperCard Pro Software is somehow strange. It tells me for one Image I have that it has 160 tracks or so on one side. All other software I know says: Two sides with 80 tracks.

[Dan-Gahlinger]

I need the offset to get half tracks, otherwise it doesn't do them.

GW seems not a mature product yet, perhaps in the future it will be useful. I can't work with it like this

---

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

I most recently tried: gw read --tracks="c=0-79:h=0:h1.off=-8" --revs=5 --retries=10 "image2.scp"

Unless you have a (kryoflux) flippy modded drive, you don't want h1.off=-8. If you have, you don't need hat when you're not reading from head 1.

Please try g64conv version 4.2 with

g64conv image2.scp image2.g64 v4000

This version has a fix for the parameter "v4000" to work.

And yes, the SuperCard Pro Software is somehow strange. It tells me for one Image I have that it has 160 tracks or so on one side. All other software I know says: Two sides with 80 tracks.

— Reply to this email directly, view it on GitHubhttps://github.com/markusC64/g64conv/issues/3#issuecomment-1026172958, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALZWUL4HR6L6NU4O75JGY23UY3VJ5ANCNFSM5KCZDHKQ. 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: @.***>