How is TD64 implemented?

[Pat the Cat]

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 EAB faq is a little unclear, it does mention there are bits of Workbench limiting drive space to 4GB but is very vague on mentioning which version of Workbench or which parts.

[giZmo350]

https://letmegooglethat.com/?q=amiga+td64

http://wiki.icomp.de/wiki/Harddrive_setup_with_TD64

[Pat the Cat]

Interesting but not a full answer.

It would appear the "Workbench changes" are activated both when a new Fast file system handler is activated AND a compatible x.device has been made active.

Otherwise no big drive luscioiusness, you might go up to fake chs and maybe even beyond if the drive gives non ATA fake chs values that work.

EDIT: Logical place to add TD64 is setpatch. Question is, which version? Obviously not one shipped with 3.1 or earlier. By CBM or Amiga Tech... although Amiga Tech appeared to have tried to add some support.

[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

[Pat the Cat]

Thanks Thomas. I wasn't thinking of patching driver or filesystem with setpatch, just wondering how the other components were updated to use big partitions.

Like I said, there are some mentions of such components "in Workbench" but no data about which components or which WB.did not need patching and would work with a correct x.driver and filesystem that used TD64.
 
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.

[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.

[olsen]

Thanks Thomas. I wasn't thinking of patching driver or filesystem with setpatch, just wondering how the other components were updated to use big partitions.

Like I said, there are some mentions of such components "in Workbench" but no data about which components or which WB.did not need patching and would work with a correct x.driver and filesystem that used TD64.

I updated workbench.library and a handful of other components (the "Info" command, for example) for Workbench 3.5 so that they would know how to handle quantities larger than 4 GiBytes. These were no fundamental changes, such as would be needed for the "DiskCopy" command, for example. Workbench 3.5 also replaced the "HDToolbox" utility with a different program which could cope much better with large storage media. The changes in the scsi.device (IDE and SCSI flavours) as well as the FastFileSystem complemented these. Still, plenty of software which shipped back then did not get updated to handle large storage media, or large numbers (in excess of 4 GiBytes).

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.

The "card.resource" and "carddisk.device" were not updated, and if I remember correctly, this is not a limitation as such. "card.resource" provides a interface to access the PCMCIA hardware, such as its chip registers. If a disk driver uses "card.resource" to access a storage device, it's the job of that disk driver to provide for large storage device command support, not "card.resource". The "carddisk.device" is a slightly different matter, as it makes the volatile/non-volatile storage on a PCMCIA card available as a local storage device. The space allotted for such cards in the larger Amiga memory space limits the size of PCMCIA card's volatile/non-volatile RAM that can be used. You won't even reach 2 GiBytes of RAM

[Thomas]

carddisk.device is not able to handle CF cards.

[olsen]

carddisk.device is not able to handle CF cards.

Could be because of its age (a bit too early for CF cards, which seem to have first hit the market around 1994) and the PCMCIA standard as implemented (1991/1992) and then frozen in time

If I remember correctly, the kind of volatile memory Commodore's implementation was designed for was either DRAM to extend the capacity of Amiga main memory, or alternatively as a RAM disk drive (RAD: implemented entirely in hardware, if you will). There was also the option to have the Amiga boot off a PCMCIA card specially prepared for the Amiga to make use of it, e.g. a game cartridge (as a more than slightly upmarket alternative to a CD-ROM disc).

[Pat the Cat]

carddisk.device is not able to handle CF cards.

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).

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

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,

Anyway, I'm just talking to myself here, seems nobody else thinking along these lines of why.

EDIT: My thinking here is that different setpatch versions on 3.1 machines do have an effect on TD64 working, Therefore, on a machine with just a 3.0 or a 2.0 setpatch, TD64 implementation is not fully present and large capacity drives (specifically PCMCIA cards) cannot work properly.

It's obviously down to me to test this hypothesis, it's not established as fact yet.

EDIT. Thank you Olsen, an old workbench,library is a definite contender. Big (>4gb) PCMCIA card seems to be working but craps out when it is filled too much.

[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.

[Pat the Cat]

... Indeed Thomas. That would explain why you couldn't help the last couple of people having no joy getting the PCMCIA cards working.

... And yet I did, for some reason.