Jump to content
IGNORED

New disk format required ?


Alfred

Recommended Posts

I was reading the SDX 4.48 manual one day and I believe I read that it supports 512 byte sectors. I'm not positive, but doesn't the MyIDE interface also support 512 byte sectors ? Are there any other interfaces that support >256 byte sectors and/or more than 65536 sectors ?

 

Either way, it occurs to me that we could use a new disk format that supports larger sectors and (maybe) larger drive sizes. The first question might then be, what are the limits of the current interfaces, and what might be a logical maximum to include future development ?

 

I know from when I was talking to Bob during the development of the Black Box he said that it supported three more bits for the sector number. With 256 byte sectors that would yield a maximum partition size of 128MB using 524K sectors. What are the maximum partition sizes for these other interfaces like MyIDE or the SiDE stuff ?

 

The second question is, are they prevalent enough to warrant a new ATR-style format for the emulators. I think they are, if only to allow for the development of software via an emulator for either current hardware or that which may yet appear.

 

If there is some other file type like ATR that does all this, then by all means, enlighten me as to what it is, and then we can forget this post.

 

 

Link to comment
Share on other sites

Most DOS's for the Atari 8-bits have a software limit of 16 bits for sector ID, which means maximum 65536 sectors. At 128 bytes per sector, this is 8MB, and 256 bytes its 16MB (normal max for ATR's and conventional Atari hard drive partitions), and yes 512 bytes per sector with newer versions of SpartaDOS X = 32MB. This works for sure on SIDE2, maybe for MyIDE2, with an added speed boost too (because it doesn't have to split the physical 512 byte sectors)

 

There's a framework in the 2.1 SpartaDOS file system for the concept of 'clusters' to allow larger partitions while still maintaining a 16-bit allocation map, and same sector size, but this is not yet implemented in the drivers.

 

The ATR file image format itself is conventionally limited to 16MB, but the header descriptor seems like it could be extended for larger sectors and size...

 

Edit: 65535 sectors max I think is an actual hard limit of the RAM SIO handler, as well as SIO protocol itself, hard to break out of that limit unless using a totally new handler type which abstracts from the sectors at a higher level, simiar to RespeQt PC-LINK, and the read-only FAT driver.

Edited by Nezgar
Link to comment
Share on other sites

Ultimate 1MB's PBI HDD BIOS (and thus SIDE/SIDE2), Incognito's CF card adapter, and IDE Plus 2.0 all support 512 byte sectors. They also all support 28-bit LBA, so the perceived 65,535 sector limit (as mentioned above) is really a limitation of DOS. The firmwares of the aforementioned devices provide an extension to the 16-bit DCB sector number to take full advantage of large physical and logical disk capacities.

 

SDX already provides FATFS.SYS, a FAT driver which can access partitions larger than the 32MB allowed by the existing SDFS implementation. Sadly the FAT driver is still read-only, but there is already ample firmware support in all popular hard disk host adpaters (at least those which support APT and XDCB protocols) for large disks.

  • Like 3
Link to comment
Share on other sites

65535 sectors max I think is an actual hard limit of the RAM SIO handler, as well as SIO protocol itself, hard to break out of that limit unless using a totally new handler type which abstracts from the sectors at a higher level, simiar to RespeQt PC-LINK, and the read-only FAT driver.

The XDCB is an extension to the DCB designed by Drac030 and has been adopted by all APT firmwares. As mentioned, it provides up to 32 bits for sector numbers and the implementation in his DracOS 65C816 OS even provides a 24-bit buffer address (also supported by extensions to the aforementioned hard disk host adapters).

  • Like 1
Link to comment
Share on other sites

The usual ATR header supports a 24-bit count of the number of 'paragraphs' (16 byte chunks) in the container, so I reckon that's a limit of 256MB. However, it's unlikely you'd want to deal which such a large volume on a serial-connected peripheral, and since the currently addressable maximum hard disk size is 137.4GB, it usually just makes sense to make an ISO of the HDD.

Edited by flashjazzcat
Link to comment
Share on other sites

Where do you get 137GB from ? 16 million sectors of 512 bytes ?

 

I guess the other question would be for Phaeron is, does Altirra support an ATR with 16 million sectors ? Offhand, I don't think it does.

Edited by Alfred
Link to comment
Share on other sites

I dunno, 16MB of 512 gives an anser of 8192MB to me. And the definition of ATR that is here http://atariage.com/forums/topic/123109-atr-format-reference/says there are only 65536 paragraphs. I also see an old thread http://atariage.com/forums/topic/155329-extending-the-atr-file-format/ about extending the format, but nothing came of it that I can tell.

 

So, it seems that we might need a new format that can handle larger sector counts, and variable sector sizes.

  • Like 1
Link to comment
Share on other sites

Um... I said the maximum hard disk size is 137.4GB, and the maximum ATR size is 256MB (assuming 24-bit paragraph count). The ATR size is governed by the metadata in the header of the container. Logical and physical hard disks have no such limitation. Subsequently I suggested that the 256MB ATR limit wasn't worth worrying about, since anything bigger than that is likely to be a hard disk partition anyway. All the modern devices deal directly with hard disk partitions (no ATR intermediary), although most of them are also capable of mounting ATRs (including ATRs with 512 byte sectors) contained inside of said partitions.

 

I guess the other question would be for Phaeron is, does Altirra support an ATR with 16 million sectors ? Offhand, I don't think it does.

Obviously not. It supports ATRs with 65,535 sectors, so a maximum of 32MB. But that's an arbitrary limit of the 16-bit DCB sector number, not the geometry data in the ATR header.

Edited by flashjazzcat
Link to comment
Share on other sites

Altirra does not support ATR images bigger than 64K sectors. There is no standard SIO command interface to access such disks, so you would not be able to use them anyway with any interface implemented in the emulator. For large hard disk images both .bin and .vhd are superior anyway as they don't misalign the sectors and VHD also supports sparse allocation, geometry metadata, and differencing disks. You can also remount VHDs in all modern OSes to directly access FAT32 partitions.

  • Like 4
Link to comment
Share on other sites

When you say Altirra supports VHD files, I have a few questions:

 

1. Do you mean VHD as used by Microsoft such as the disk images used for Hyper-V (not including the VHDX ones) or do you mean some custom Atari format that uses the same extension letters ?

 

2. How can such VHD files be attached ? Do they require that they be attached via an interface like MyIDE, or can they be directly attached as D1: etc ? I'm ignoring the issue regarding DOS support, just asking in terms of raw device i/o.

 

3. Assuming they can be attached directly as D1:, how (or if) is the issue of sectors 1-3 handled ? Does Altirra just do what the DCB implies (ie. length =128 so only reads/writes 128) or does Altirra ignore the length and return the full sector size as specified in the VHD and its up to the software to partition the returned data ?

Link to comment
Share on other sites

When you say Altirra supports VHD files, I have a few questions:

 

1. Do you mean VHD as used by Microsoft such as the disk images used for Hyper-V (not including the VHDX ones) or do you mean some custom Atari format that uses the same extension letters ?

It is the same format, mountable in Windows 7+ Disk Management / Diskpart.exe and in all major VM software. Altirra only supports plain VHD, not VHDX.

 

2. How can such VHD files be attached ? Do they require that they be attached via an interface like MyIDE, or can they be directly attached as D1: etc ? I'm ignoring the issue regarding DOS support, just asking in terms of raw device i/o.

Hard disk interfaces only. The VHD format is inefficient for small disk images.

 

3. Assuming they can be attached directly as D1:, how (or if) is the issue of sectors 1-3 handled ? Does Altirra just do what the DCB implies (ie. length =128 so only reads/writes 128) or does Altirra ignore the length and return the full sector size as specified in the VHD and its up to the software to partition the returned data ?

 

Emulators can't use the size from the DCB, as this is not visible for transfers over the SIO bus. The intended transfer length is only visible if an OS-level patch hook is being used.

 

There are no short boot sectors for the hard disk interfaces. For the floppy disk drive protocol, Altirra uses 3 128-byte boot sectors for sector sizes below 512 bytes and no boot sectors for 512 bytes and above. The latter is required by SpartaDOS 4.40+, which assumes a 512 byte boot sector. There is a weird case of ATR files with 8192 byte sectors, which are used by some cartridge flashing programs when flashing from an SIO2PC style device -- not sure if anyone tries to boot off disks with such huge sectors.

Link to comment
Share on other sites

Respect also has the 8192 bytes / sector 'large' atr feature. I use this with flashing The!cart. 128MegaBytes. Not the sizes mentioned here, but still.

 

@Guus : although I used to think like that... I never understood why I would want a 32Mb partition on a8, now I use it .... and it is full now too, while I absolutely would love to have more space on that partition. So... although I agree that a8 system is already excellent, It is never finished of course.

Link to comment
Share on other sites

Um... I said the maximum hard disk size is 137.4GB, and the maximum ATR size is 256MB (assuming 24-bit paragraph count)

Actually ATR allows up to 64GB maximum (32 bit paragaph count, 2^36-1 bytes max size).

 

See the SIO2PC docs http://pages.suddenlink.net/wa5bdu/readme.txt

STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:

 

It's extremely simple. There is first a 16 byte header with the following

information:

 

WORD = special code* indicating this is an Atari disk file

WORD = size of this disk image, in paragraphs (size/16)

WORD = sector size. (128 or 256) bytes/sector

WORD = high part of size, in paragraphs (added by REV 3.00)

BYTE = disk flags such as copy protection and write protect; see copy

protection chapter.

WORD=1st (or typical) bad sector; see copy protection chapter.

SPARES 5 unused (spare) header bytes (contain zeroes)

It looks like APE uses a slight variation with the high part of size stored as a single byte and 2 bytes CRC where the MSB of the size and the disk flags are stored. Yes, the nice thing about standards is that there are so many of them...

 

I wouldn't use ATR for storing harddrive images though, as phaeron wrote there are far better, standard formats available for that purpose.

 

so long,

 

Hias

  • Like 1
Link to comment
Share on other sites

It looks like APE uses a slight variation with the high part of size stored as a single byte and 2 bytes CRC where the MSB of the size and the disk flags are stored. Yes, the nice thing about standards is that there are so many of them...

Exactly. It's long been debated, and you just have to pick one and assume it's wrong. ;) Better yet, try to ignore what's not part of the basic spec.

 

I wouldn't use ATR for storing harddrive images though, as phaeron wrote there are far better, standard formats available for that purpose.

I agree. And as I wrote earlier, in most situations where one would like to use an ATR for backups, the amounts of data involved are not well suited to the serial devices commonly used for hosting ATRs. Even if a "PIO2PC" existed, if would probably be better to cut ties with ATRs and use VHDs, etc. Sure there are some cases where ATRs are practical for backing up partitions (put a 32MB ATR in a FAT partition on a CF card, mount it using U1MB/SIDE2, and perform a raw sector backup at reasonable speed), but more often than not it's easier to just put the media in the PC and back it up that way.

  • Like 1
Link to comment
Share on other sites

Exactly. It's long been debated, and you just have to pick one and assume it's wrong. ;) Better yet, try to ignore what's not part of the basic spec.

Basic spec before formats branched away seems to be 2 bytes for paragraphs, 2^20-1 ~=1MB :)

 

The APE CRC bytes are usually 0, and if they are set one can rather easily guess if there are 3 or 4 size bytes by looking at the real file size and/or the sector size.

 

It's a bit academic since there are currently no users of ATRs larger than 128MB, but with 8k sectors a 32768 sectors image would already be above what the APE format can represent.

 

As we don't have plans to create a 256MB or larger The!Cart this is going to stay academic for a quite while and the simple approach of checking just 3 size bytes should also be fine for now :)

 

so long,

 

Hias

Edited by HiassofT
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...