PackDev (.pkd) image support for PC disks?

[mark_k]

Is WinUAE supposed to support PackDev images of PC format disks? Because selecting a .pkd file of a DD or HD PC format disk in the WinUAE floppy drives page doesn't seem to work.

[Toni Wilen]

Need example file before I can reply

[mark_k]

Attached is an archive with example PC/MS-DOS 3.5" DD (720KB), 3.5" HD (1440KB) and 5.25" DD (360KB, 40 cylinders) PackDev images. (Remove the ".remove.zip" from the filename, it's an XZ-compressed tar archive, but the EAB forum doesn't allow attaching files which end in .xz)

[Toni Wilen]

There was 2 problems, pkd always unpacked to Amiga DD size (There are Amiga .dsq images that are smaller than DD for some reason), now it only pads size to 880k if header information has surfaces==2 and sectors==11.

Second problem was name of image, only known extensions use size based heuristics to detect the type (if size is 720K = DOS disk and so on). Now it also checks "internal" generated name (PC_3.5_DD.pkd unpacked memory "file" is named as PC_3.5_DD.pkd.adf) if it has known extension.

btw, your images are interesting, they have surfaces==1 and sectors==2*real value. I guess there was no standard..

[mark_k]

Originally Posted by Toni Wilen

There was 2 problems, pkd always unpacked to Amiga DD size (There are Amiga .dsq images that are smaller than DD for some reason), now it only pads size to 880k if header information has surfaces==2 and sectors==11.

Could those smaller images have been related to only storing used blocks in the .pkd/dsq file? I never used that feature myself, always using PackDev's ALL option.

Originally Posted by Toni Wilen

btw, your images are interesting, they have surfaces==1 and sectors==2*real value. I guess there was no standard..

Do you mean that's what is specified in the DOS boot sector, or the PackDev image header?

I created the example images by mounting PC0: (CrossDOS, mount file has Reserved=1), formatting it then copying a file to the disk. Then PackDev FROM PC0: to filename.pkd ALL

The reserved value in the header of the example images was set to 1. However in some other .pkd files I created from PC disks, the reserved value is 2. For PC disks probably 1 makes more sense. Maybe I was using a different mount file with Reserved=2 back when I created those other .pkd images???

The .pkd format header seems to contain the number of sectors, sector size, number of reserved sectors and track size. It doesn't specify the number of surfaces. PackDev source code is on Aminet. Without looking at that though, just using a hex editor, the .pkd header seems to consist of:

Offset  What
------  ----
00      50 4B 44 13
04      Total number of sectors, longword
08      Sector size in bytes (e.g. $00000200)
0C      Number of reserved sectors, e.g. 1 or 2.
10      Size of each track in bytes, e.g. $00001200 = 9*512 for PC 5.25" DD

Edit to add: the 50 4B 44 13 is PKD in ASCII, followed by the minimum version of PackDev able to unpack the file, seemingly in BCD. So $13 means version 1.3 or later needed here.

[Toni Wilen]

I thought reserved sectors field was number of heads field. I didn't have any documentation when I added .pkd support, I simply guessed how it works.

It could explain size problem too..

[mark_k]

On the subject of PackDev...

PackDev is supposed to support trackdisk sector label data. [In the Amiga trackdisk floppy disk format, each sector has an associated 16-byte "label area". Thus the total amount of data that can be put on a disk using normal trackdisk device commands (not TD_RAWREAD) is (512+16)×1760 = 929280 bytes. Most programs don't use sector label data, and of course it can't be recorded in a normal 901120-byte ADF file.]

On creating a .pkd image file from a floppy disk, the sector label data is supposed to be recorded in the image file. When writing a .pkd file back to floppy disk, you can tell PackDev to write the sector label data by using the ETDFORMAT or TDFLABEL options.

I don't know of any programs which write to the sector label area. So I experimented using PackDev by creating a .pkd image of a formatted floppy disk (AllZeroSectorLabels.pkd). Then I used a hex editor to change some of the sector label data to non-zero bytes, calling the modified file SomeSectorLabelData.pkd. (See from offset $1634 in SomeSectorLabelData.pkd.)

In WinUAE I created an extended ADF file and put that in DF0:. Then I used PackDev to write SomeSectorLabelData.pkd to that disk with ETDFORMAT.

Finally I used PackDev again to create an image file from the just-written-to disk. In theory the new image file should be identical to SomeSectorLabelData.pkd. But in fact the new image file is identical to AllZeroSectorLabels.pkd.

Am I doing something wrong or is PackDev's support for sector label data broken? I don't think it would be a WinUAE problem, unless for some reason WinUAE detects a trackdisk-format track is being written and zeros out all the sector label data???

[Toni Wilen]

I think I simply made it to ignore sector headers, I didn't see any reason to have internal pkd to ext adf converter ("not worth the trouble"). I have never seen any programs that use sectors headers.

[mark_k]

Yes I figured that WinUAE's .pkd file support probably ignored sector label data. However I wasn't using WinUAE's .pkd file support for the testing above. An extended ADF was in DF0:. In the emulated Amiga, I did
PackDev FROM SomeSectorLabelData.pkd TO DF0: ETDF
then read that back with
PackDev FROM DF0: to read_from_df0.pkd ALL
And after that, read_from_df0.pkd had all its sector label data zero.

[Toni Wilen]

Check log, it wanted to write non-zero sector header(s) if it says "Disk decode: sector X header: A B C D".