Single-sided PC/ST disk image support?

[mark_k]

Is WinUAE supposed to work with images of single-sided PC/ST disks? For example the Atari-Utilities disk from Chamäleon II ST emulator:

http://www.media!fire.com/file/wlcsyi0p25babcd/Atari-Utilities.tar.gz

Plain binary, PackDev and MFMWarp images in that archive. [The MFMWarp image is huge because all tracks on side 1 are blank/unrecorded.]

On inserting the binary (renamed to end in .img because...) or PackDev images in drive 0, there are lines like this in the log:
Disk decode: checksum error on sector 0 header
Disk decode: weird sector number 184 (aa8ab8d6, 160)
Disk decode: checksum error on sector 0 header
Disk decode: weird sector number 255 (ffdfffd7, 810)

And doing Dir PC0: shows a load of garbled text instead of the proper directory listing. Or is there something about the ST disk filesystem layout which CrossDOS doesn't like?

[Toni Wilen]

It was detected as double sided 360k floppy. Which wouldn't be compatible with Amiga drive anyway, so only do that if 5.25" drive is selected..

[mark_k]

Thanks. It seems PackDev doesn't record the number of heads/surfaces in its header so you can't easily see whether a .pkd image is single-sided 80-track, or double-sided 40-track.

By the way, CrossDOS can double-step heads to read 40-track disks in 80-track drives. (80-track 5.25" drives sold for Amiga use appeared the same as a normal external 3.5" drive to software.)

[Toni Wilen]

Originally Posted by mark_k

Thanks. It seems PackDev doesn't record the number of heads/surfaces in its header so you can't easily see whether a .pkd image is single-sided 80-track, or double-sided 40-track.

Transferring this information from depacker to disk emulation would be too difficult and I wouldn't be surprised that many programs would have included bad geometry..

By the way, CrossDOS can double-step heads to read 40-track disks in 80-track drives. (80-track 5.25" drives sold for Amiga use appeared the same as a normal external 3.5" drive to software.)

I added 5.25DD option so that this can be emulated

If 5.25DD and 40 track image: tracks are duplicated to make it 80 track.

(Not tested)

[mark_k]

Not sure it makes sense to add another floppy drive type, because from a software perspective it's identical to 3.5" DD 80-track. Best just to, for any 40-track image, double the tracks when inserted into an 80-track drive.

There were probably (almost?) no IBM PC-compatibles which used 3.5" 40-track drives, but other computers might have, e.g. some Acorn Electron or ZX Spectrum drives. The Amiga XFS package could possibly be used to read those. Its readme mentions a 40-track single-sided Spectrum format.

BTW, 5.25" SD as a drive type is a misnomer, better to have 5.25" 40-track instead.

[Toni Wilen]

See above. It is only logical method to separate between 720k single sided and 360k double sided images (both are exactly same size)

[mark_k]

Another case where you can't determine disk type from image file size would be PC 10 sectors/track, A-Max and Emplant disk formats, all of which are 800KB.

I'm not sure how A-Max format differs from PC 10-sector since CrossDOS seems to support both. [You can use A-Max-format disks with ShapeShifter via (I assume) mfm.device. Could they be identical???]

Anyway... what I'd suggest is having drop-downs for both drive type and disk type. When you can determine disk type automatically (i.e. 901120 bytes => Amiga trackdisk) that drop-down would be greyed out. If the user chooses an 800KB disk image, the disk type drop-down could offer PC, A-Max and Emplant options.

Another drive type is the Power HD floppy. There's a post from its designer here. Maybe emulation of that would not be completely useless if someone wants to make sure their code works with that product?

[Toni Wilen]

I don't like disk type selections, no one knows what to choose..

Also, few example files required first.

[mark_k]

In the usual case there would be nothing to choose of course.

I've created some example extended ADFs in both A-Max and Emplant formats. BTW I think mfm.device (at least v41.47) supports both A-Max and Emplant formats, so it may be possible to convert/create disks in one or the other format without needing the ConverterII program which came with Emplant.

Ideally, support for plain disk images and Apple Disk Copy v4.2 images would be great to have too.

Archive with example images uploaded to:

https://www.media!fire.com/file/bm0autj6v1p878u/Disk9.tar.gz

Disk9_A-Max.extadf - Blank ext.ADF created with old WinUAE version when chipset set to PAL (so has too-short track lengths). Written to A-Max format using ConverterII in PAL emulation.

Disk9_Emplant.extadf - Blank ext.ADF created with (I think) recent winuae.exe when chipset set to NTSC. ConverterII used to write disk in Emplant format.

Disk9.image - (Data fork of) image file created using Apple Disk Copy 4.2, running under A-Max II. The source disk was A-Max format which had been written by ConverterII.
Some notes on the Apple Disk Copy file format at https://wiki.68kmla.org/DiskCopy_4.2..._specification
Note: The Macintosh 400K/800K physical disk format apparently has 12 bytes "tag data" along with each 512-byte sector. Analogous to Amiga trackdisk "sector label data" I guess. ConverterII must put "DREW (C)1993" in the tag data for every sector when writing an image to disk, because if you load the file into a hex editor, you'll notice that string repeated many times near the end.

Disk9.convII - An image file created using ConverterII from Emplant. This has a simple 32-byte header followed by 819,200 bytes sector data. This image format doesn't contain tag data. Or at least, this specific file doesn't. Header consists of:

Offset	What
0	"DREW (C)1994" 12 ASCII characters
$0C	$01
$0D-0F	00 00 00
$10.L	$000C8000 Length of all sector data; 819200 here for an 800KB disk
$14-1F	00 bytes

I tried initialising a disk as single-sided (400KB) in A-Max II, but got an "Initialization failed!" message at the end every time. I'm assuming that would also happen on real hardware. Maybe the A-Max floppy driver just wasn't tested or intended to support 400KB disks?

[mark_k]

Over in this thread demolition uploaded raw dumps of 800KB and 1600KB PC-format disks (10 sectors/track). It turns out that CrossDOS works with/recognises that type of disk. There's also a 1581-format dump which may use the same or similar physical format.

So that's four types of disk which could have the same length of image file: A-Max, Emplant, PC 10-sector, 1581.

If you implement auto-detect and manual selection of disk type, in the normal case the user could just leave it at auto.

If "LK" in first two bytes assume Mac disk, so A-Max or Emplant format. Maybe default to A-Max since there's no Emplant board emulation yet. You could also check for a DOS BPB in the first sector, if geometry matches image size then default to that disk format. Similar detection could differentiate between 40-track double-sided and 80-track single-sided (typically Atari ST) images.

[Toni Wilen]

Yeah but only Amiga and PC images are directly supported, I don't see any use for directly supporting any other non-raw image format and raw images work automatically.

[mark_k]

The main use would be to make using Mac emulators easier. Given Mac (800K) disk images, you need to use ConverterII to write/convert each to an extended ADF beforehand.

[Toni Wilen]

But someone still needs to write UAE internal converter to support those images first..

[mark_k]

Right. I'm hoping that PC 10-sector/track images would be quite easy since 9-sector images are already supported. Basically just smaller inter-sector gaps?

Following on from that, I'm also hoping that A-Max or Emplant formats are closely related to 10-sector PC.

[Toni Wilen]

10 track PC images should be already supported. (9, 10, 18, 20 and 21 are included in detection list)

[mark_k]

Aha, just checked and indeed it does support them! (I originally had the image filename ending .bin and WinUAE requires .img in order for the detection to work…)

[JimDrew]

Originally Posted by mark_k

If "LK" in first two bytes assume Mac disk, so A-Max or Emplant format.

Not quite. The LK will only be there if the disk is a bootable Mac disk. That LK is the start of the Mac's boot code. Mac disks need to have their directory tree checked to determine what type they are. Checking just block 0 will only tell you if it is bootable, not that it is Mac format.