markusC64
Converting SCP to G64 skips half-tracks
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?
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.
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.
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...
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.
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
Here is an example of an scp file with half tracks. Please remove extension .zip, so you have a .7z file.
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: @.***>
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: @.***>
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.
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...
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: @.***>
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: @.***>
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...
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: @.***>
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.
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: @.***>
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.
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: @.***>
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: @.***>
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: @.***>
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.
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.
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: @.***>
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.
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: @.***>
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...
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: @.***>
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: @.***>
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.
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: @.***>