Ultrasatan ICD PC Readable SD Card?

[cleverr1]

Hi,

Has anyone managed to create an ICD Pro based SD card for Ultrasatan with Atari STE with partitions that can be read and written on a Windows 10 PC?

 

After trying and failing I bought the PP driver which was simple to get working in this way, but I'm still curious about how the PC compatible ICD Pro cards that appear on eBay are created.

 

Thanks

[ParanoidLittleMan]

As I know they are only DOS compatible, so not TOS compatible too. You need program BigDOS to access them with Atari ST(E)/TOS .

[cleverr1]

I've just discovered that this is a duplicate post of:

So as you explained, TOS/DOS needs a special driver on the Atari ST.

[ParanoidLittleMan]

Yes, special driver in needed for TOS/DOS compatible partitions. But you need first to create them - and that is done by partitioner program in TOS/DOS driver SW package.

[cleverr1]

2 hours ago, ParanoidLittleMan said:

Yes, special driver in needed for TOS/DOS compatible partitions. But you need first to create them - and that is done by partitioner program in TOS/DOS driver SW package.

I tried partitioning using the PP tool but I was then unable to make it bootable with ICD Pro.

 

Do you have the details of the driver package that can create a TOS/DOS partition that works with ICD Pro?

Edited August 28, 2020 by cleverr1

[ParanoidLittleMan]

That's not possible. Quoting you: "TOS/DOS needs a special driver on the Atari ST. " .

[cleverr1]

The documentation I found around this (Exxoshost - Atari_HD_File_Sytem_Reference_Guide.pdf) quotes:

2.4.3 Creating TOS&DOS partitions TOS&DOS partitions can only be created by PPDRIVER and HDDRIVER packages. Only use TOS&DOS partitions with the matching driver (as they are not compatible) and never use them with any other driver (see § 2.3 for important warning).

 IMPORTANT WARNING: A TOS&DOS partition is not a regular TOS partition and therefore it should only be accessed on the Atari with the matching hard disk driver. For example using the ICD AdSCSI hard disk driver gives the impression to access TOS&DOS partitions correctly (it even report correctly the size) but if you try to read beyond the first 32MB of the partition you will get incorrect results and even worse if you try to write you will definitively corrupt the partition.

 

So if this is correct I don't understand how the ICD Pro driver could work on a drive a PC can see.

 

It's only a moot point because the PP driver does everything required here. It's just curiosity.

[ParanoidLittleMan]

OK, here are some technical details:

DOS partitions and TOS partitions are FAT16 system. And they are same until 32 MB size. In 90-es I used DOS partitions with diverse drivers - like little modded AHDI, after realized that TOS does not deal with master boot sector (MBR) where are details of partitions on media. TOS (AHDI) uses different data structure. But since driver SW deals with it, no real sense to go on AHDI type MBR, DOS type is OK, and then it is directly accessible with DOS/PC, later with Windows 95 and followers, Linux, MAC OS.  Because hard disk sizes were small, 32 MB partitions were OK. I had drives from 40 to 160 MB in beginning.

 

The difference starts above 32 MB partition sizes, and such partitions are called BigDOS or BigGEM . Main difference is that TOS uses still 16-bit sector addressing, while it is normally enough for partitions up to 32 MB (65536 sectors) . And that's possible only when increase logical sector size - so in case of partitions in range 256-512 MB logical sector size is 8 KB, or 16x reg. sector size. And must say here that it is not good. It means need for larger buffers, more data transferred - even if need only 512 bytes must transfer 1 full logical sector, so 8 KB.  In addition, max count of clusters (so files too) in 1 partition is not 2 POW 16, but 2 POW 15 . Normally 1 cluster is 2 sectors, so with 8 KB logical sectors could/should have 1 GB max partition size .

I'm pretty much sure that the reason for this is used C-Compiler Alcyon, what had problems with unsigned integers, so they used signed ones, and that means 15 instead 16 bits.

 

And I guess that ICD just wanted DOS compatibility, so they added support for DOS type MBR. And as said, max 32 MB partitions were fine in those years.

 

Little more about this here:  http://atari.8bitchip.info/imptosf16.html

 

 

[cleverr1]

Hi,

Thanks, this is deep stuff to me! I get the 8KB sector size inefficiency issue, but whilst it's not elegant, with such big drives available the inherent problem becomes somewhat obfuscated.

 

Since being initially interested in the technical side of this I've since appreciated why your drivers are exactly what's needed. They just work - Kudos Fella!

[ParanoidLittleMan]

"I get the 8KB sector size inefficiency issue, but whilst it's not elegant, with such big drives available the inherent problem becomes somewhat obfuscated. "

 

Well, it means not that with 8KB sectors data takes much more space on disk than with 512 byte sectors.  Minimal size on disk what 1 short file takes in case of 8KB sectors is 16 KB with usual FAT16 - because 1 cluster is 2 sectors - TOS type partition. That's for partition sizes 256-512 MB. DOS type partition can have in such case have 8 KB size clusters, what self lowers little slack (wasted disk space). That's not so much, less than 10 % in normal usage.

Inefficiency is mostly because need to transfer always 8KB or multiple of it data, because can operate only with whole logical sectors. That causes slower work, and again, it is not so much, probably around 10%, but that somehow looks for me worse than that wasted space. And more RAM used by OS - with 512 byte sectors 2 KB is enough for disk buffers (and so much is already reserved, for floppies, and same buffers can be used with  hard disks). With 8 KB sectors need 32 KB buffer size, what is still not so much, for sure. But when it can be better without extra HW and even without longer code in TOS ROM that's just bad. And for end: ST = sixteen/thirty two - CPU is 32-bit in big part (except data bus and some rare used operations), and they still went on 16-bit sector addressing ?