D64 export as SCP crash

General discussion forum - for all that doesn't fit in any other category.
ILAH
Posts: 8
Joined: Wed Jun 10, 2020 7:46 pm

Re: D64 export as SCP crash

Post by ILAH »


JimDrew
Posts: 30
Joined: Fri Dec 06, 2013 7:52 am

Re: D64 export as SCP crash

Post by JimDrew »

Jeff wrote:
Thu Jun 11, 2020 11:35 am
ILAH wrote:
Wed Jun 10, 2020 7:54 pm
P.S.I got the hint in the Greaseweazle FB group that scp rrack table should be 168 entries instead of 166.
And about this, this is not really true, the number of entries change regularly. You can't expect to have the same number of entries in all SCP files.

See :
Untitled.png


Still have a doubt about the min/max track fields so i mailed JimDrew to clarify this point.
I did not receive an email from you about this. Yes, there are 168 entries. 166 entries was images up to v1.4 of the specification. You can easily check the version number in the file and determine what to follow.

I just looked at the .scp image file you are generating from a .d64 file. The C64 is a special case where half tracks are stored in head 1's position (as the odd tracks). The min/max or heads thing is wrong though. Let me figure out what the issue is.

JimDrew
Posts: 30
Joined: Fri Dec 06, 2013 7:52 am

Re: D64 export as SCP crash

Post by JimDrew »

OK, I looked at the .scp file again. With the CBM disk type, each track uses two entries (main track and half track). So, the max track is double. Right now, HxC is converting a .d64 as a max track of 0x22. It should be setting this to 0x44. Byte 0x0A in the HxC conversion is 0x01, which is correct. I ignore this byte myself when I know the disk type is CBM because I know the track arrangement has only a single head.

So,it looks like you just need to double the max track value and the conversion will be perfect. I did that with a sample image and I was able to convert that to a .g64 file and use it under VICE.

JimDrew
Posts: 30
Joined: Fri Dec 06, 2013 7:52 am

Re: D64 export as SCP crash

Post by JimDrew »

One other thing... after looking at literally thousands of SCP dumps of Commodore (1541) disks I have come to realize that nearly every person using SuperCard Pro is making images with a 96 TPI 5.25" drive. So, you might want to make the FLAGS 0x07 (instead of 0x01) and make the flux timing for a 360 RPM drive instead of a 300 RPM drive. Most utilities are going to expect that and may not even work with 300 RPMs images. Maybe an option in your config menu would be nice to output either 300 RPM or 360 RPM for any 5.25" disk format (setting the FLAG byte appropriately of course!).

Jeff
Site Admin
Posts: 8092
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: D64 export as SCP crash

Post by Jeff »

JimDrew wrote:
Wed Jun 17, 2020 3:00 am
OK, I looked at the .scp file again. With the CBM disk type, each track uses two entries (main track and half track). So, the max track is double.
[...]
So,it looks like you just need to double the max track value and the conversion will be perfect.
Is this rule only true for CBM disk type or all single sided images ?

Does the min/max track field need to be doubled for others single sided images ?

JimDrew
Posts: 30
Joined: Fri Dec 06, 2013 7:52 am

Re: D64 export as SCP crash

Post by JimDrew »

This rule applies to all single-sided 40 track formats. This is why the manufacturer/disk type is important to be correct! Because most 40 track disks (Commodore, Apple II, etc.) can have 1/2 tracks, the only way to support this was to treat all 40 track formats as if they were 80 tracks. I have updated the SuperCard Pro specification. The latest version is here:

https://www.cbmstuff.com/downloads.htm

Pay attention to the special notes section:

Code: Select all

IMPORTANT NOTE ABOUT SINGLE SIDED 40 TRACK DISK IMAGE FILES
-----------------------------------------------------------
Commodore GCR (1541/1571/compatibles), Apple II, and other disks that are 40 track
formats can have half-tracks between the full tracks.  To support this, ALL single
sided 40 track disk types have the start and end track numbers doubled, and 80 tracks of
space are used.  So, each track number represents either a full track or a half-track.
Example:

START TRACK: 0 - physical track 0, track 1.0 for CBM disks
END TRACK: 71 - physical track 71, track 35.5 for CBM disks

START TRACK: 6 - physical track 6, track 4.0 for CBM disks
START TRACK: 7 - physical track 7, track 4.5 for CBM disks

*** NOTE *** CBM, Apple II, and possibly other disk formats refer to their first track as "1",
not "0" as with most other formats.  In the above examples you would subtract 1 from the
CBM track number, and divide by 2 to obtain the physical offset of the track data in the
image file.  The .5 track indicates a half-track.

A 96 TPI 5.25" disk drive is REQUIRED in order to make images of single sided 40 track disks
WITH half tracks.  You can use a 48 TPI drive to make images of single sided 40 track disks
without the half-track support (the half-track entries will all be empty).  You can not use a
48 TPI drive to make images of any disk that has a 80 track format.
I was told that your HxC image files are not generating 168 track TDH entries. You are apparently still generating the old standard of 166 entries. You probably need to change that to support the extra last track that was added years ago. MAKE SURE you are also setting the disk type byte correctly for the format!

Jeff
Site Admin
Posts: 8092
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: D64 export as SCP crash

Post by Jeff »

JimDrew wrote:
Wed Jun 17, 2020 9:00 pm
This rule applies to all single-sided 40 track formats. This is why the manufacturer/disk type is important to be correct! Because most 40 track disks (Commodore, Apple II, etc.) can have 1/2 tracks, the only way to support this was to treat all 40 track formats as if they were 80 tracks. I have updated the SuperCard Pro specification. The latest version is here:

https://www.cbmstuff.com/downloads.htm

Pay attention to the special notes section:

Code: Select all

IMPORTANT NOTE ABOUT SINGLE SIDED 40 TRACK DISK IMAGE FILES
-----------------------------------------------------------
Commodore GCR (1541/1571/compatibles), Apple II, and other disks that are 40 track
formats can have half-tracks between the full tracks.  To support this, ALL single
sided 40 track disk types have the start and end track numbers doubled, and 80 tracks of
space are used.  So, each track number represents either a full track or a half-track.
Example:

START TRACK: 0 - physical track 0, track 1.0 for CBM disks
END TRACK: 71 - physical track 71, track 35.5 for CBM disks

START TRACK: 6 - physical track 6, track 4.0 for CBM disks
START TRACK: 7 - physical track 7, track 4.5 for CBM disks

*** NOTE *** CBM, Apple II, and possibly other disk formats refer to their first track as "1",
not "0" as with most other formats.  In the above examples you would subtract 1 from the
CBM track number, and divide by 2 to obtain the physical offset of the track data in the
image file.  The .5 track indicates a half-track.

A 96 TPI 5.25" disk drive is REQUIRED in order to make images of single sided 40 track disks
WITH half tracks.  You can use a 48 TPI drive to make images of single sided 40 track disks
without the half-track support (the half-track entries will all be empty).  You can not use a
48 TPI drive to make images of any disk that has a 80 track format.
Ok so this now raise a new question :

Is there a difference with the TDH entries filling method between a 80 tracks singled sided image and a 40 tracks singled sided image with half tracks ?

I think that you should provide some SCP images as examples :

- 80 tracks double sided.
- 80 tracks single sided.
- 40 tracks double sided - double step/with half tracks.
- 40 tracks double sided - single step.
- 40 tracks single sided - double step/with half tracks.
- 40 tracks single sided - single step.

This will help to have the whole picture :).
JimDrew wrote:
Wed Jun 17, 2020 9:00 pm
I was told that your HxC image files are not generating 168 track TDH entries. You are apparently still generating the old standard of 166 entries. You probably need to change that to support the extra last track that was added years ago.
Until some days ago there was conflicting informations about the TDH entries and the max track in the specification:
Tracks are numbered 0-165,
which is a maximum of 166 tracks (83 tracks with top/bottom).
MAKE SURE you are also setting the disk type byte correctly for the format!
Can't promise. Many raw/images files have very ambiguous origin/ "disk type" information. But will try to do something for the most critical cases.

JimDrew
Posts: 30
Joined: Fri Dec 06, 2013 7:52 am

Re: D64 export as SCP crash

Post by JimDrew »

I will work on some example files.

Single-sided 40 track and 80 track images will basically be identical. The difference being that the half-tracks are every other track with a 40 track format, and actual full tracks with a 80 track format. The manufacturer/disk type is used to help determine how the user should see the data. In reality if you just write all 80 tracks worth of data of a single sided image to a disk with a 96 TPI drive it won't matter what the disk type is. You of course skip any TDH entry that is 0x00000000, so you CAN make 40 track disk images that don't have any half-tracks. This is required when using a 48 TPI drive, where half-tracks don't exist.

Single and double stepping is solely determined by the disk drive itself, not by the .scp image file format - although the drive type (48/96 TPI) is stored for reference (bit 1 of the FLAGS byte). Whatever is using the .scp image file should take into account that a 80 track image can not be written on a 48 TPI drive. Likewise a 40 track image with half-tracks can not be written on a 48 TPI drive unless half-tracks are ignored and only the full track is written.

Double-sided disks are always stored with the head 0 (bottom) being in even entries and head 1 (top) in odd entries. There are no half-tracks possible with 40 track/double-sided disk images.

Yeah, I was recently made aware that I had some places with the old examples of 0-165. That was fixed.

Jeff
Site Admin
Posts: 8092
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: D64 export as SCP crash

Post by Jeff »

JimDrew wrote:
Wed Jun 17, 2020 11:00 pm
I will work on some example files.
Yes please ! :) Official reference / test cases are very important !

(And ideally with some old revision SCPs too : This is interesting to check the backward compatibility).

JimDrew
Posts: 30
Joined: Fri Dec 06, 2013 7:52 am

Re: D64 export as SCP crash

Post by JimDrew »

There were no changes made to ever affect backwards compatibility. I just didn't have some information published. The change to adding an extra track for floppy disks was made at the request of some crazy European guy who insisted that his 1541 had copy protection on track 84. :)

deBUG
Posts: 1
Joined: Wed Jul 21, 2021 12:38 pm

Re: D64 export as SCP crash

Post by deBUG »

By any chance is conversion from a d81 scp to d81 possible ? So one can use a flux device for everything ? :-) )

(I know I can use a bunch of SAMDISKs or omniflops to write and read d81s on windows but I use Linux !)

Post Reply