To use original 3” +3 disks you’ll need a 3” drive and a special cable [link currently dead] to connect it to your PC.
If you’re only looking to use existing software images it may be easier to connect a 3.5” drive to your +3 instead. Most commercial software is hard-coded to access A:, so you’ll need replace the internal drive or connect externally and have a switch to swap them.
To create a disk image from an existing +3 disk use:
SAMdisk a: image.dsk -c42 -h0
That reads 42 tracks from the first side of the disk, which should cover 99% of +3 titles. You can change the name of the output image, but keep the .dsk file extension so it’s created in EDSK format.
To write a +3 disk image back to a real disk use:
SAMdisk image.dsk a:
The default behaviour writes all tracks in the source image, but you can specify your own range to override that. Adding -c42 -h0 ensures that exactly 42 tracks are written to the first side only, ignoring any extra tracks or padding shorter images with blank tracks.
Most +3 disks are supported automatically, even if they include custom formatting tricks such as mixed sector sizes, 8K sectors, fake error sectors, etc. A couple of disk systems require special attention to ensure they’re written accurately enough to pass copy-protection checks.
Examples: After Burner, Barbarian 2, Buggy Boy, Chase HQ 2, Robocop, W.E.C. Le Mans, …
The protection is on cyl 0, and appears as a 9-sector track with the 2nd sector (id=2) showing a data CRC error. The contents of the error sector change between successive reads, with either all or just part of the contents appearing different. Some of the remaining sectors may also have a deleted data address mark.
250Kbps MFM, 9 sectors, 512 bytes/sector:
0.0 1 2[m3,dc] 3d 4d 5d 6d 7d 8d 9
diff(72): =256 -32 +48 -176
This example represents a partially weak sector; the first 256 bytes of the sector are the same each time, the next ~32 bytes differ between reads, a further ~48 bytes are filler bytes (but have changing value), and the final ~176 bytes differ between reads. In some early versions of Speedlock the weak and filler blocks were 16 and 64 bytes in length, respectively.
The protection checks vary between titles, but in all cases it reads up to 3 copies of the sector and expects to encounter a data CRC error and a difference between the copies read. In some versions of the protection it checks for unchanging filler at the start of the data field. Some also check for a patch of filler bytes beyond the weak area.
To write the weak sector SAMdisk prepares the track area using an 07 filler written at 300Kbps, which was found to be particularly effective at losing FDC sync when the data is read back at a normal 250Kbps. A normal sector header and data address mark is then written to overlap the ‘weak’ area, followed by the required number of constant bytes in the data area. For partially weak sectors a constant block of 256+80=336 bytes followed by a weak area of 176 bytes is sufficient to satisfy all known variations of the protection check.
For this protection to work in emulators they must support the EDSK extension to use multiple copies of error sectors, ideally cycling through the different data copies each time the sector is read. Fuse, SpecEmu and Spin support this, though other emulators may vary the final byte in the sector in order to pass the weak data check.
Examples: 2x1 (Corsarios y MutanZone), …
The protected track is on cyl 40, where the final sector (id=8) has a size code of 8 (32K).
250Kbps MFM, 9 sectors, 256 bytes/sector:
40.0 0 1 2 3 4 5 6 7 8[n8,dc]
The protection reads sectors 7 and 8, and compares 255 bytes from sector 7 with the data at offset 1298 (hex 512) in sector 8, to ensure they match.
This isn’t a particularly difficult protection, but use of a sector size >=7 has traditionally meant no sector data was stored in EDSK dumps of it, so the protection check failed. My EDSK extension to store the full native data size (32K for sizes >= 8) is enough to preserve the protection data.
Writing the protection back requires care is taken with the final large sector. Error sectors that extend beyond the track wrapping point are automatically truncated to fit the available space, which keeps the protection intact.
Emulator support requires the 32K sector is handled correctly, and that the source disk image also includes the extra data.
Examples: Coin-Op Hits
At first glance the track format appears like others using 8K sectors:
250Kbps MFM, 1 sector, 8192 bytes:
1.0 1d[dc]
In most cases 8K sectors hold 6145 bytes of usable data. This is 6144 bytes of sector data, plus an XOR checksum byte (since the normal FDC CRC can’t be used). I’ve yet to see a loader that tests the checksum byte, but SAMdisk will warn if it’s present and bad. Older EDSK dumps are missing the checksum so it’s impossible to tell if the tracks are bad.
Coin-Op Hits is special because the 8K sectors hold a whopping 6305 bytes of usable data. This is more than the usual 6250 bytes of raw track capacity for 250Kbps double-density track at 300rpm. It’s also beyond the 6144 bytes stored in older EDSK images, and the reason old dumps of this game never worked.
The extra space was gained by writing the disk with a slightly narrower bit-cell width, which squeezes all bits together slightly. This is still within the PLL tolerance for the FDC, so the disks can still be read. For original disks this just means changing a parameter in the trace machine script used to write the disk. Writing the disk image back to floppy on the PC is more of a challenge.
The bit-cell width of the written data depends on the data rate and drive rotation speed. The FDC has 4 fixed data rates, with no room for minor adjustments. Fortunatly, 3” drives have a potentiometer in the motor housing, allowing the drive speed to be adjusted manually.
Reducing the rotation speed from 300rpm to around 292rpm gives enough space for the Coin-Op Hits disk to be written. However, you also need to use the --calibrate option so SAMdisk knows about the extra track space.
The speed of modern 3.5” drives is controlled by a fixed-rating resonator, so adjusting the speed is unlikely to be a trivial modification. That makes Coin-Op Hits one of the few +3 titles that can’t easily be played from a 3.5” drive — you’ll need a KryoFlux for that.
Some games were found not to work from 3.5” disks, even though the same image was fine when written to a 3” disk. Affected titles would usually reset immediately upon booting.
When control is passed from +3DOS to the disk boot sector code, the floppy drive motor is switched off. One of the first things the boot sector does is switch the motor back on, and after doing so it should wait for the motor to stabilise before issuing further commands; failing to wait may cause the next operation to fail.
The heavier 3” drive mechanism loses very little speed during the brief motor-off period, so the next read request will usually succeed. The 3.5” drive mechanism loses more speed, causing the next read request to fail. If the loader code is not willing to retry the read then it won’t work on a 3.5” drive.
SAMdisk recognises some loaders affected by the problem and will apply a work-around patch to fix it. This only happens when writing to real disks, unless --fix is used to forcibly fix it. Using --no-fix will prevent the fix being applied.
The bulk of the affected titles are using the Alkatraz disk system. Also affected are some Infogrames and Erbe titles, the UbiSoft games Twin World and Iron Lord, and Shadow Warriors.
Many thanks to Krasimir Hristov, Andrew Barker, Mark Woodmass, Davide Guida, Fred Jan Kraan and István Fábián, for help with testing and providing details and sample images.