How is TD64 implemented?

[Thomas]

Is all the large capacity magic put solely into the drive type driver x.device, or are other libraries and modules involved with making TD64 "happen" on an Amiga and large drives (>8Gib) to become usable.

The limit arises at the interface between file system and device driver. The interface is defined by a struct IOStdReq which is sent by the file system to the driver to access data on the drive.

http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0621.html

The structure uses a byte offset to address the place where on the drive to start. As all values are stored as 32bit integers, the limit is 2^32 bytes which is exactly 4 GB.

TD64 now uses the io_Actual field, which normaly is an output field set by the device driver, as the upper 32 bits for the input offset. This way you can address bytes by a 64 bit offset.

http://aminet.net/package/dev/misc/trackdisk64.lha

To exploit this trick, both the file system and the device driver must be aware of the mechanism. You cannot simply patch TD64 into some components (like with SetPatch), you really have to replace both participants by new versions.

See also: http://thomas-rapp.homepage.t-online.de/4gb_faq.html

[Thomas]

The point being at which point a floppy only user could use a PCMCIA adapter with larger than 4GB partitions on it with legacy Commodore disks.

Workbench is not involved in large hard disk support. As mentioned the limit is in the interface between file system and device driver. In case of reading a FAT formatted CF card on the PCMCIA port the components you need are FAT95 and compactflash.device. Both support TD64, so there is no size limit for the CF card. Both require at least Kickstart 2.0, so Kick 1.3 is out of question, but any OS version from 2.0 onwards can read any size of CF card.

Workbench and other components might have different issues, though. AmigaDOS reports disk size and free space as number of sectors and sector size. Coders tend to just multiply them using 32 bit math and print the result. But 32 bit math overflows at 4GB, so the result for large drives is wrong. Either the coder has to consider special cases when using 32 bit math or use 64 bit math (which is not so easy because compilers might not support that). In any case these issues have to be solved for each individual software product, they cannot be fixed by a global patch.

[Thomas]

carddisk.device is not able to handle CF cards.

[Thomas]

In terms of using them, it seems that way At least Prepcard can read the card vendor and type (if it's on the card).

Reading vendor and product data is a PCMCIA standard, it works for all cartridges independent of their purpose.

However, floppy users seem to have a problem with using large PCMCIA cards (over 2GB).

There is a hit and miss of which CF cards work or don't work. Some work on IDE only, some on PCMCIA only or all other combinations. It has nothing to do with the software configuration or the size of the CF cards. Sometimes larger CF cards even work better than smaller ones.

I can't help but thing it is not just compactflash.device involved, setpatch if the only component that is involved with the process for users with old ROMs and new hard drives,

There are patches for PCMCIA hardware bugs. See CardPatch and CardReset on Aminet. This has nothing to do with large harddrive support.

SetPatch of OS 3.5+ patches NSD support into many devices. But it does not enable large harddrive support. Only by chance if the device already supports TD64 or Direct-SCSI but not NSD-TD64.

Big (>4gb) PCMCIA card seems to be working but craps out when it is filled too much.

The opposite is true. It fails to display large sizes and thus large amounts of free space lead to erroneous "drive full" conditions.