IDE Plus 2.0 - new IDE host adapter

[flashjazzcat]

Ok, I checked the size when I was creating the external reference to FAT and seen that it has 35536 sectors. I guess that's the problem, FDISK defaults to that number of sectors if one enters 32MB when creating the FAT partition, but I will do what you asked as well.

I take it you mean 65536 sectors, which is mathematically equivalent to 32MB. So you should indeed try 31.9995MB, which equates to 65535 sectors. That's the maximum (16 bit) sector range SDX can currently handle.

Edited January 20, 2014 by flashjazzcat

[atari8warez]

atariwarez: open the offending partition in Eddy, sector 1, and, if possible, make a photo of the screen so that the contents of the sector 1 (i.e. the numbers) are clearly visible. It is enough to show first 256 bytes. I can then find out why the driver is rejecting that partition.

 

Here are the pics Conrad:

 

[atari8warez]

I take it you mean 65536 sectors, which is mathematically equivalent to 32MB. So you should indeed try 31.9995MB, which equates to 65535 sectors. That's the maximum (16 bit) sector range SDX can currently handle.

 

Yup typo there , there were 65536 sectors, I have since changed it to 31MB but it is still "unknown file system", man this wasn't really difficult before I am not sure what I am doing wrong!!...

[flashjazzcat]

Partition's 65536 sectors in the screengrab, but if making it smaller hasn't helped... hmmm.

Edited January 21, 2014 by flashjazzcat

[atari8warez]

Partition's too big.

 

Is that from the pictures.??... so what number should I enter into FDISK or should I format the FAT in Windows.

[flashjazzcat]

Can't keep up here... am on one of those infernal touch-screen keyboards. Yeah: try anything less than 32MB. Format FAT16 in Windows, ideally with (IIRC) 8K cluster size.

[atari8warez]

Ok will do that

[atari8warez]

@conrad / @fjc

 

External partition still doesn't work ("Unknown file system") even after:

 

- I make a smaller 28MB partition in FDISK from scratch, take the CF Card to the laptop, Windows sees the partition and I copy some files in it,

 

- Take the card back to the Atari, create an external reference to FAT16 partition in FDISK,

 

- FDISK shows FAT partition size as 31MB (?) before creating the external reference,

 

- Take Properties after creating the external reference and the properties screen shows 28MB (correct) as the partition size,

 

- Activate it, assign drive number D8: to it, write the partition info to disk and exit FDISK,

 

- Reboot the ATARI with FATFS.SYS, do a DIR 8:, I get the message "Unknown file system".

 

- Do a DISKINFO, it shows 57120 as the sector count, FDISK however showed 57344 total sectors after the external reference is created

 

- I am lost at this point

 

Here are the screenshots:

 

 

 

 

 

 

Edited January 21, 2014 by atari8warez

[drac030]

@atariwarez: thanks for the info and pics, but the Eddy one does not show what I meant. I wanted the first sector of the partition, not of the entire disk. Please select Edit->Disk (not Edit->Device) and open the first sector of a partition for which you get the "Unknown file system" error.

[flashjazzcat]

@atariwarez: thanks for the info and pics, but the Eddy one does not show what I meant. I wanted the first sector of the partition, not of the entire disk. Please select Edit->Disk (not Edit->Device) and open the first sector of a partition for which you get the "Unknown file system" error.

At least we discovered from those screenshots that the partition was one sector too large.

 

External partition still doesn't work ("Unknown file system") even after:

 

- I make a smaller 28MB partition in FDISK from scratch...

 

- FDISK shows FAT partition size as 31MB (?) before creating the external reference...

When building the table of FAT partitions, the standard Microsoft algorithm is used to derive the FAT size from the FAT's boot sector. Only when the FAT partition is unformatted is the FAT type and size derived directly from the information in the MBR partition table.

 

The discrepancy between the calculated FAT size and the raw partition size could be caused by a formatting issue, or some bug elsewhere; I guess we will know more from looking at the boot sector.

 

- Take Properties after creating the external reference and the properties screen shows 28MB (correct) as the partition size

Again, this is the raw partition size (since partition properties has to work with partition entries of any type, not just FAT), so will always report the same whether the partition is formatted or not.

 

- Do a DISKINFO, it shows 57120 as the sector count, FDISK however showed 57344 total sectors after the external reference is created

57344 sectors = 28MB.

Edited January 21, 2014 by flashjazzcat

[drac030]

The MBR snapshot turns out to be useful anyway: the partition type of the first entry (byte $01C2) is $0C -> FAT32.

 

http://en.wikipedia.org/wiki/Partition_type

 

The second entry has correct $7F -> APT container.

Edited January 21, 2014 by drac030

[flashjazzcat]

Well aware of the correct partition types, but clearly in this case the user created a FAT32 partition using Disk->Initialize, and then forcibly formatted it FAT16 in Windows. Note also that (as previously stated) FDISK (in the external partition list) has deduced the FAT type not from the MBR partition ID, but from the FAT geometry.

 

In any case: does this make any difference to the situation at hand: i.e. why would the driver care which partition ID is in use?

Edited January 21, 2014 by flashjazzcat

[drac030]

The driver does not care on the MBR partition type. I just guess that the FS on the partition is still FAT32, just resized down to 28 MB. But of course I am eager to see the actual bootsector contents, it may as well prove my theory wrong.

[atari8warez]

Well aware of the correct partition types, but clearly in this case the user created a FAT32 partition using Disk->Initialize, and then forcibly formatted it FAT16 in Windows.

 

Nope, that's not the case, "the user" in this case did not format the disk in Windows, simply created a 28MB partition in FDISK, the partition was recognized in Windows when the CF card is moved to the PC, files were copied into the partition then the CF card was returned to the Atari. I have a feeling that some previous info on the disk surface somehow incarnated into the "newly" created partition, the reason I think that way is because whenever I started and completed a brand new partitioning session and then move the card to the Windows machine, I see the files in the partition reincarnated. Maybe it is wise to wipe the partition and FAT areas before starting a new partitioning session. I am just thinking out laud here and I may be wrong in my assumptions.

 

I also noticed a MSDOS5.0 string looking at EDDY screens, as far as I know FAT16 has two versions, earlier version's (I believe up to DOS 3.31) support less than 65536 sectors - type 0x04, whereas latest FAT16B supports65536 sectors and more - type 0x06. Anyway since I am not an expert on DOS systems and don't know MBR, VBR etc offsets by heart I'll leave further examination/discussion to you guys

 

Here's the 1st sector of the unrecognized disk (D8: or H)

 

Edited January 21, 2014 by atari8warez

[drac030]

atariwarez, thank you, that is most useful.

 

Bytes $13-$14 of the bootsector: value $0000 means "disk bigger than 65535 sectors". This is the direct reason why FATFS.SYS is rejecting the partition and returning error 148.

 

At offset $20-$23 there is a 32-bit sector count, used when the $13-$14 word is zero. This one says $00010000 - 65536 sectors.

Edited January 21, 2014 by drac030

[flashjazzcat]

Nope, that's not the case, "the user" in this case did not format the disk in Windows, simply created a 28MB partition in FDISK, the partition was recognized in Windows when the CF card is moved to the PC, files were copied into the partition then the CF card was returned to the Atari. I have a feeling that some previous info on the disk surface somehow incarnated into the "newly" created partition, the reason I think that way is because whenever I started and completed a brand new partitioning session and then move the card to the Windows machine, I see the files in the partition reincarnated. Maybe it is wise to wipe the partition and FAT areas before starting a new partitioning session. I am just thinking out laud here and I may be wrong in my assumptions.

If the starting sector of the partition remains unchanged, then it's likely that the FAT boot sector from a previous partitioning session will remain intact. This is rather useful when one's intention is to rescue a corrupt MBR, and since the boot sector isn't wiped automatically I'd recommend formatting freshly created partitions before use as per the standard procedure for setting up disks on just about every platform imaginable.

 

But this has nothing to do with the partition ID shown in your screen shot. FDISK simply obeys the user's wishes when creating the FAT, and will not create a FAT entry of partition type $0C (FAT32) when the user selected FAT16 in the disk initialisation dialogue. So regardless of any amount of mitigating circumstances, the user in this case clearly left "FAT32" selected while initialising the disk when there was already a FAT16 boot sector (or FAT32 sized down to FAT16, as Konrad said) occupying sector 63, and didn't subsequently format it. This is why the partition with ID $0C was identified as FAT16.

Edited January 21, 2014 by flashjazzcat

[flashjazzcat]

I also noticed a MSDOS5.0 string looking at EDDY screens, as far as I know FAT16 has two versions, earlier version's (I believe up to DOS 3.31) support less than 65536 sectors - type 0x04, whereas latest FAT16B supports65536 sectors and more - type 0x06. Anyway since I am not an expert on DOS systems and don't know MBR, VBR etc offsets by heart I'll leave further examination/discussion to you guys

Yes, that would be partition type 4 which FDISK automatically creates if you define a FAT16 partition of less than 65536 sectors.

[atari8warez]

If the starting sector of the partition remains unchanged, then it's likely that the FAT boot sector from a previous partitioning session will remain intact. This is rather useful when one's intention is to rescue a corrupt MBR, and since the boot sector isn't wiped automatically I'd recommend formatting freshly created partitions before use as per the standard procedure for setting up disks on just about every platform imaginable.

 

So are you saying that if I create a new FAT16 partition from scratch in FDISK then take the card to the PC and format it in the PC, copy some files to it, then take the card back to Atari and use FDISK to create a reference to the external FAT partition, make it active, write it to disk, exit and reboot Atari with FATFS.SYS loaded, I should be able to access the the drive (D8: in this case)

 

But this has nothing to do with the partition ID shown in your screen shot. FDISK simply obeys the user's wishes when creating the FAT, and will not create a FAT entry of partition type $0C (FAT32) when the user selected FAT16 in the disk initialisation dialogue. So regardless of any amount of mitigating circumstances, the user in this case clearly left "FAT32" selected while initialising the disk when there was already a FAT16 boot sector (or FAT32 sized down to FAT16, as Konrad said) occupying sector 63, and didn't subsequently format it. This is why the partition with ID $0C was identified as FAT16.

 

All i can say to this is that I never created a FAT32 partition on the CF card, why would I do such a thing when I DO KNOW that the current SDX FAT driver will not be able to access it

[flashjazzcat]

So are you saying that if I create a new FAT16 partition from scratch in FDISK then take the card to the PC and format it in the PC, copy some files to it, then take the card back to Atari and use FDISK to create a reference to the external FAT partition, make it active, write it to disk, exit and reboot Atari with FATFS.SYS loaded, I should be able to access the the drive (D8: in this case)

Well, I can't speak on behalf of the driver, but in theory, yes. It's the way I've always done it.

 

All i can say to this is that I never created a FAT32 partition on the CF card, why would I do such a thing when I DO KNOW that the current SDX FAT driver will not be able to access it

Come, come, you must have, since how else would that $0C partition ID have found its way into the MBR partition table? We already know FDISK doesn't put it there if you select FAT16, so I'd suggest a slip of the fingers when choosing between FAT16 and FAT32. Fortunately there are no serious criminal repercussions to such a mistake, so I wouldn't worry about it.

[atari8warez]

Ok, I've just performed the exact procedure outlined in my previous message and it works now, HOWEVER one advise to other users is that when you format the partition in Windows MAKE SURE NOT TO DO A QUICK FORMAT, in other words clear the "Perform a quick format" check box in the format dialog before hitting the OK button. You must wipe the disk clean otherwise you never know what you end up with when "your finger slips" and you take the card back to Atari

 

I still would suggest that FDISK should wipe any previous data before starting a new partitioning session, recovery is a good excuse not to do it, but in fact if a user starts a new partitioning session s/he clearly has no intention to recover that disk, s/he just wants to start fresh from the beginning (In fact "initialization" should mean just that, starting from an initial clean state)

Edited January 21, 2014 by atari8warez

[flashjazzcat]

Ok, I've just performed the exact procedure outlined in my previous message and it works now, HOWEVER one advise to other users is that when you format the partition in Windows MAKE SURE NOT TO DO A QUICK FORMAT, in other words clear the "Perform a quick format" check box in the format dialog before hitting the OK button. You must wipe the disk clean otherwise you never know what you end up with when "your finger slips" and you take the card back to Atari

 

I still would suggest that FDISK should wipe any previous data before starting a new partitioning session, recovery is a good excuse not to do it, but in fact if a user starts a new partitioning session s/he clearly has no intention to recover that disk, s/he just wants to start fresh from the beginning (In fact "initialization" should mean just that, starting from an initial clean state)

Bing Translation:

 

Yes - I left FAT32 selected by accident

Some interesting suggestions there, but I'm not absolutely convinced these urgent recommendations would have come about if the user hadn't made a series of small procedural errors in the first place.

 

Nope, that's not the case, "the user" in this case did not format the disk in Windows...

Interesting also that a complete absence of formatting has now become a "quick format". I'm quite surprised that a quick format (assuming it actually happened and that we're not just pulling words out of a hat here) to a file system different to that currently on the disk would leave the boot sector arranged for the previous file system, but I'll take that as read until I get around to testing the theory.

[Marius]

Fdisk should not wipe ANY userdata!

It's a partition program which edits the partition table; nothing more nothing less.

 

Formatting/wiping is something the dos should always take care of IMHO.

 

 

[atari8warez]

Bing Translation:

 

 

Some interesting suggestions there, but I'm not absolutely convinced these urgent recommendations would have come about if the user hadn't made a series of small procedural errors in the first place.

 

 

Interesting also that a complete absence of formatting has now become a "quick format". I'm quite surprised that a quick format (assuming it actually happened and that we're not just pulling words out of a hat here) to a file system different to that currently on the disk would leave the boot sector arranged for the previous file system, but I'll take that as read until I get around to testing the theory.

 

I repeat here for the last time, I never created a FAT32 partition for the reason I stated earlier... Secondly when I said i didn't do a format in Windows I was referring to my last attempt only, not many other previous ones where I did in fact format the partition, but with the option "quick format",

 

".......a Full format will truly scrub through the hard drive from scratch, rebuild all of its file structures, and scans the drive to make sure that everything is on a satisfactory level. On the other hand, what a Quick format does is lay down a blank FAT and directory table without checking for bad sectors."

 

You may also want to do something about the confusion the initialization steps cause, because when you do want to redo partitions from scratch FDISK uses old values from the disk in certain places (like when creating external references).

 

For example, on a previously formatted disk with a 28MB partition, and when that partition is being re-created with a new 32MB size, FDISK shows the partition size as 27MB (curiously not 28!) instead of 32MB when one creates an external reference.

 

In my opinion the size shown on that "External Partition" window should reflect the new size (besides since after one enters the new partition size, and FDISK displays "Write to disk: are you sure" and the user presses OK ,and then FDISK supposedly writes the new value to disk, why on earth would the old size still be visible in the "External Partition" window !?).

 

In any case these are my suggestions, whether you see them useful is a whole different story. IMO In any solid software "Procedural Errors" (i.e. user errors) must be reduced to minimum especially in a critical software like a partition editor, not many users know how a disk is laid out and whether they should do a full format or quick format

 

Video: Re-partitioning a CF card which has previously been partitioned to a single 28MB FAT16 partition:

 

Edited January 21, 2014 by atari8warez

[atari8warez]

Fdisk should not wipe ANY userdata!

It's a partition program which edits the partition table; nothing more nothing less.

 

Formatting/wiping is something the dos should always take care of IMHO.

 

No it should not, it should however wipe the old partitioning information, what we are talking here is not the user data on the disk

[flashjazzcat]

I repeat here for the last time, I never created a FAT32 partition for the reason I stated earlier... Secondly when I said i didn't do a format in Windows I was referring to my last attempt only, not many other previous ones where I did in fact format the partition, but with the option "quick format",

You used FDISK to create an MBR partition entry of type $0C by leaving "FAT32" selected in the disk initialization dialogue. That is the basic user oversight I wanted confirming (since the implication was otherwise that FDISK might create a partition of type $0C when FAT16 was selected, which is demonstrably not the case).

 

You may also want to do something about the confusion the initialization steps cause, because when you do want to redo partitions from scratch FDISK uses old values from the disk in certain places (like when creating external references).

On the other hand you might want to routinely format partitions after you create them. I can't really do anything about confusion caused by an inability to comprehend that the partitioning structure and the formatted data areas of the disk are two separate entities. While it's possible to "hand-hold" to a certain extent in software, when it comes to the creation of "external partitions", I at least expect from the user some passing familiarity with the concepts of disk partitioning and formatting. Otherwise the user might be best advised to avoid more advanced partitioning operations entirely, regardless of the fact the partitioning software attempts to present two co-existing partitioning structures as simple list boxes with familiar UI elements and asks nothing more of the user than to remember what it is they just did, and to have some vague notion of what needs to be done next.

 

For example, on a previously formatted disk with a 28MB partition, and when that partition is being re-created with a new 32MB size, FDISK shows the partition size as 27MB (curiously not 28!) instead of 32MB when one creates an external reference.

If you go and look up Microsoft's official algorithm for divining the FAT scheme on a disk, you'll see that the capacity reported is that of the data cluster area, and not the attendant FAT structures. Note that the detection method employed is the de-facto method recommended by the people who gave us the FAT file structure.

 

Regarding the reported partition size: it should by now be clear to all but the most mentally hampered that leaving the boot record of the 28MB partition in the first sector of the newly created 32MB partition (by failing to format the new partition) will cause the "de-facto, Microsoft-approved" FAT detection algorithm to report the old geometry of the volume.

 

In my opinion the size shown on that "External Partition" window should reflect the new size (besides since after one enters the new partition size, and FDISK displays "Write to disk: are you sure" and the user presses OK ,and then FDISK supposedly writes the new value to disk, why on earth would the old size still be visible in the "External Partition" window !?).

The discrepancy between the data cluster size returned by the MS FAT detection algorithm and the "raw" partition size is a valid consideration, and something I've been mulling over. Maybe it's best to always use the raw partition size regardless of the size of the FAT data cluster area. Certainly something I can fix up at my leisure.

 

As to the second point, I'll just repeat verbatim what I wrote above:

 

"Regarding the reported partition size: it should by now be clear to all but the most mentally hampered that leaving the boot record of the 28MB partition in the first sector of the newly created 32MB partition (by failing to format the new partition) will cause the "de-facto, Microsoft-approved" FAT detection algorithm to report the old geometry of the volume."

 

In any case these are my suggestions, whether you see them useful is a whole different story. IMO In any solid software "Procedural Errors" (i.e. user errors) must be reduced to minimum especially in a critical software like a partition editor, not many users know how a disk is laid out and whether they should do a full format or quick format.

One of them was kind of useful; the rest of the complaints come across as petty nit-picking, frankly, from someone who enjoys winding people up and is unable to accept any responsibility for what - to begin with - were perfectly reasonable oversights and misunderstandings of the kind many users might encounter when attempting to get external partitions working, but which have somehow given flight to these great exegeses of self-righteous bewilderment and detailed accounts of breathtaking user incompetence of a kind I have truthfully not witnessed even in the least technical users (much less "developers") during some three years of manufacturing partitioning software for the 8-bit Atari. It seems the quest to protect the user from the dizzying complexity of these operations was in vain after all.

 

I'll politely avoid issuing any of the obvious retorts to the remark about "solid software".

 

 

No it should not, it should however wipe the old partitioning information, what we are talking here is not the user data on the disk

But it does wipe the old partitioning information. Boot records are part of the "user data" (for want of a better term) on the disk.

 

Now, if none of the above is yet clear, please pursue the line of complaint elsewhere instead of continuing to clutter up this thread with your italicised and emboldened diatribes.