Jump to content
IGNORED

IDE Plus 2.0 - new IDE host adapter


drac030

Recommended Posts

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.

 

I perfectly understand that the partitioning structure and the formatted data areas are two separate entities, what you do not seem to understand however is the integrity in between the two and the importance of preserving it. Another thing you seem to ignore is the fact that some real life event may force the user to postpone formatting to a later time and s/he may forget to do it altogether.

 

Now in the light of the above facts let's see how Microsoft handles partition editing in Windows:

  • User cannot change a formatted FAT partition without deleting it first and then re-creating it from scratch (you cannot extend or shrink it like you do with volumes). The size shown to the user is the new size, not the size of the old partition, so there is no confusion there. The new partition will not be accessible for data storage until you format it. All of these make sure that disk/data integrity is preserved and there are no loose ends. Pretty basic, but bulletproof so far.

Now let’s see how your implementation of partitioning works:

  • User can change the partition size at will, even though FDISK warns users every time the structure is changed and the new structure is written to the disk, it does not really take any measures to prevent the usage of the changed partition until it is formatted, this leaves many open doors for mistakes can cause data integrity problems if the user forgets to format the partition, some examples with SDX and Windows:

 

  • If the changed partition was active at the time of the change and the user returns back to DOS, the drive ID associated with that partition continues to be active but the DOS is unaware of the change and thinks it is still using the same drive geometry, thus:

  • User may do a CHKDSK in SDX and get wrong sector counts, capacities and even wrong sector sizes.

  • User may try to copy new files to that changed drive with who knows what kind of results

  • If the user takes the CF card back to Windows PC the partition will still be treated as formatted and a drive letter will be assigned to it, the drive will be usable although with a different size then it actually has. Because the old FAT structure is still there and the files are still visible and accessible there is nothing to remind the user that s/he has to format the partition

  • User may copy new files to that drive and while some files can be copied successfully, some (depending on their size) will result in unexpected strange errors like 0x80070057 (which is in fact not strange given the partition is actually corrupt)

 

 

These are only a few scenarios that actually happened to me and I am not a casual computer user by any standards, just imagine people with no technical background. Microsoft gives the user tools to do things but also makes those tools as bulletproof as possible, I just can’t see why it should be any different in Atariland, is it because this is just a hobby or is it because you think that everybody in Atariland has to have the same technical knowledge as you do?.

 

Blaming “user errors” for software weaknesses to me is just not respecting your user base enough and a lame excuse for leaving loose ends, and that’s true whether you are in business or hobby. I am not saying a software cannot have weaknesses or bugs, all software do, it is how you approach the problems when they surface, whether they be design issues or bugs.

 

So my suggestion is to make the new partition inaccessible to user and to DOS until it is properly formatted. If that’s not possible, you could even offer a formatting option (like Windows partition editor does) as a last step in the partitioning process, if that’s not possible for technical reasons either, you could at the least warn the user that the partition should not be used until formatted.

 

I am also hoping that a complete and up to date user manual will eventually be available but I can’t hold my breath for that seeing that good user manuals for software/hardware are hard to come by in the contemporary Atariland :)

 

These are only my suggestions and you are of course free to take them seriously or not at all, after all it is your software, but please refrain from personal attacks as you did in your previous reply, they are not productive.

Edited by atari8warez
Link to comment
Share on other sites

 

 

So my suggestion is to make the new partition inaccessible to user and to DOS until it is properly formatted. If that’s not possible, you could even offer a formatting option (like Windows partition editor does) as a last step in the partitioning process, if that’s not possible for technical reasons either, you could at the least warn the user that the partition should not be used until formatted.

 

 

I think this a bad idea, because of the reason I posted earlier. It's simply the DOS that should take care of formatting (it is the Disk Operating System).

Also it can be interesting or needed to be able to access a partition that isn't formatted at all.

 

Although I think it does not belong in a FDISK program, I can imagine that a formatting option is a nice idea, the blackbox had a built-in formatter too (you created a partition, and you could format it in MyDOS or SpartaFormat).

Edited by ProWizard
Link to comment
Share on other sites

I do not think actual formatting should take place in FDISK, as this means embedding a more complex code to create and access user data. But one may think that invalidating the FS on the partition in question may be a sufficient option. It would be probably enough to zero-out sector 1 and sector $0168 to kill almost any FS which is currently in use on Atari.

 

"Almost", because this will not invalidate - just possibly damage - CP/M FS. This FS is hardly used, but it can serve as an example of a potential risk of touching user data in FDISK - as it is not the purpose of the program to make any access to the logical drives, any "invalidation" it could do, must be done blindly, which in turn may be at least inefficient.

 

This is the case with partitions internal to the APT containter. For the external ones, I am not so sure.

Edited by drac030
Link to comment
Share on other sites

I think this a bad idea, because of the reason I posted earlier. It's simply the DOS that should take care of formatting (it is the Disk Operating System).

Also it can be interesting or needed to be able to access a partition that isn't formatted at all.

 

Although I think it does not belong in a FDISK program, I can imagine that a formatting option is a nice idea, the blackbox had a built-in formatter too (you created a partition, and you could format it in MyDOS or SpartaFormat).

I do not think actual formatting should take place in FDISK, as this means accessing user data. But one may think that invalidating the FS on the partition in question may be a sufficient option. It would be probably enough to zero-out sector 1 and sector $0168 to kill almost any FS which is currently in use on Atari.

 

"Almost", because this will not invalidate - just possibly damage - CP/M FS. This FS is hardly used, but it can serve as an example of a potential risk of touching user data in FDISK - as it is not the purpose of the program to make any access to the logical drives, any "invalidation" it could do, must be done blindly, which in turn may be at least inefficient.

 

This is the case with partitions internal to the APT containter. For the external ones, I am not so sure.

The ability to format the data area certainly does not belong in the partitioning program, and even just erasing an arbitrary sector (say - sector one) is not guaranteed to completely invalidate the file system in use, as Konrad points out.

 

I prefer not to and indeed do not make any changes to the data inside partitions. FDISK does, however, read data in the user area in order to establish for sure which FAT filesystem is in use. The reason for this - if not already exhaustingly apparent - is that you're pretty much free to format a FAT partition with any FAT variation you like, regardless of its MBR partition ID. Want to format type $0C with FAT16? Nothing stopping you from doing that, and we've already seen pertinent evidence that this is the case when the user selected a FAT32 partition in FDISK, only to treat it as a FAT16 partition later on.

 

So, then, assuming the user has already prepared his media somewhere else (for example, using a partition manager in Windows which allows multiple FATs on removable media, and permits the manual insertion of an APT partition type $7F), and formatted all the partitions according to his whims, how best are we to deduce whether a given partition is FAT16, FAT32, or something else? We certainly can't rely on the MBR partition table ID, since this could easily be discrepant with the file system in use, unless the user is careful enough to always manually ensure he gives the partition the correct ID in the first place. We've already seen that the casual user is unlikely to be concerned with such things, however.

 

The solution is pretty obvious, and is a side-effect of the remedy to the problem I was already intending to fix: namely that FAT volume sizes derived from analysis of the file system did not exactly match the "raw" partition size the user sees elsewhere.

 

So going forward, FDISK will completely ignore the file system at all times, relying solely on the MBR partition ID as a means of identifying the external partition. If the partition is $04 (FAT16, less than 65,536 sectors) and you previously somehow formatted the partition FAT32, the partition will still be identified FAT16, because its MBR partition ID is $04. If this change introduces more opportunities for heightened confusion among those who have imposed the goal of divine perfection on this free partitioning tool, then that's just too bad, although I'm confident that if things had worked this way in the first place, I would have been criticised for not analysing the file system to intuit the partition type. C'est la vie.

 

As well as this, to further avert the risk of absolute confoundment in the user, the reported FAT sizes in the External Partition dialogue are now correct to four decimal places, just as elsewhere in the application.

 

The version of FDISK which conforms to these changes is already prepared and will be uploaded elsewhere presently. :)

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

 

I think this a bad idea, because of the reason I posted earlier. It's simply the DOS that should take care of formatting (it is the Disk Operating System).

Also it can be interesting or needed to be able to access a partition that isn't formatted at all.

 

Although I think it does not belong in a FDISK program, I can imagine that a formatting option is a nice idea, the blackbox had a built-in formatter too (you created a partition, and you could format it in MyDOS or SpartaFormat).

 

What I said was is to "offer the option" of formatting the disk, whether the actual format code is included in the FDISK or not could be debated, if its not included with FDISK then a hook to an external format program could be made (you can see Windows partition editor for clues).

It's simply looking for trouble leaving the disk half-prepared with FDISK while it is still accessible.

 

After all if we decided to use FAT partitions in Atari world and we decided to make changes to the disk geometry with FDISK we should also have the tools required to format the disk rather then relying on Microsoft to complete the task. Perhaps Conrad would be kind enough to write a formatting utility or enhance FORMAT.COM which already exists in SDX.

 

 

 

I do not think actual formatting should take place in FDISK, as this means embedding a more complex code to create and access user data. But one may think that invalidating the FS on the partition in question may be a sufficient option. It would be probably enough to zero-out sector 1 and sector $0168 to kill almost any FS which is currently in use on Atari.

 

Yes, something that will make the use of the disk impossible until it is properly formatted.

 

 

The version of FDISK which conforms to these changes is already prepared and will be uploaded elsewhere presently. :)

 

Just the expected knee jerk reaction :)

Edited by atari8warez
Link to comment
Share on other sites

  • 1 year later...
  • 6 months later...
  • 3 weeks later...

Is there a labeled picture or diagram somewhere that shows the buttons, switches, etc. on the IDE+2 Rev D? There may have been in this thread at one time, but the photos have been replaced with advertisements. I'd like to be able to print the pic and add it to my docs. I understand that some of these features are not enabled at this time, but I wanted to have the info in my documentation. (P.S. I looked but didn't see this info in the latest pdf manual.)

 

Thanks,

Larry

Link to comment
Share on other sites

Hi Konrad-

 

Thanks! Yes, I do remember that pic! Maybe I added the text to Simius' picture? Definitely forgot that. Translated the web page and transferred it to WORD and its now with the other IDE+2 docs, so I should be able to find it the next time I need to look at it.

 

-Larry

Link to comment
Share on other sites

  • 4 months later...

This only has a bios 1.3, and had thought the Atari community was going to get a new update to version 1.4

Yes, I realized that the release of the 1.4 is already delayed, it is two years since 1.3 came out, sorry for that.

 

Unfortunately, no great new features, mostly just bugfixes in this release.

 

Also, there is some change in the way the NVRAM is being handled, so, after reflashing the BIOS, the first reset/power up will reset the NVRAM setting to the "factory" state. Do not panic then, just set them anew and save (Ctrl/B or Ctrl/X).

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Sorry to dig up this thread, but am having peculiar difficulties getting REALDOS & SpartaDOS 3.33 to boot on the 2.0+ Rev D.

 

Any help is appreciated. This is my second to last effort to put the Bates Motel, back online. The Black Box just stopped working and I cannot figure out why, so I switched to a IDE2.0+ Rev. D. I can copy files and everything, I can boot from it, BUT the boot hangs. Either with a blank screen (Sparta) or with it partially through the startup process (RealDOS). It never gets to the dos prompt in either.

 

Connect IDE2+ to 130XE with drive in place.

Run FDISK
Partition Drive
Set main partition to be bootable
go to IDE2+ config screen set boot drive to D5:
Set D1 swap to On
CONFIG.SYS set to D5:
Execute a ^B
Use SDX to Build Directory
Copy REAL_32.DOS from a known good ATR (via SIO2USB & SIO2SD) to drive
execute "BOOT REAL_32.DOS" at command prompt
execute "COLD /CN" (as well as trying "COLD /C") as well as turning SDX off via switch on mainboard AND trying via config screen
Hang. Same place, every time
Link to comment
Share on other sites

You don't specify the BPS 128, 256, 512.. Disk based SpartaDos on a hard drive likes to have 256k Sectors to look at and I believe that RealDos like to have 256k sectors also.. I never use Cart based Format on SDX44x

you should try to stick with FMTDIR or a RealDos hard drive format program..

 

 

post-10165-0-39415100-1460017554_thumb.png

  • Like 1
Link to comment
Share on other sites

Just a thought but if this is the same machine you were having issues with the black box on have you tried a different Atari? Perhaps the problem is in the computer not the peripherals?

 

 

I try everything on a modified 800XL (x2), a stock 800XL, a stock 130XE and a modified 800 (incognito). I cannot think of any other permutations of test machines that would give additional information.

Link to comment
Share on other sites

You don't specify the BPS 128, 256, 512.. Disk based SpartaDos on a hard drive likes to have 256k Sectors to look at and I believe that RealDos like to have 256k sectors also.. I never use Cart based Format on SDX44x

you should try to stick with FMTDIR or a RealDos hard drive format program..

 

 

attachicon.gifCapture.PNG

 

 

Hmm, well, that may be it. I formatted at 512 BPS. In fact, I did everything at 512 BPS. I will reformat and try again.

 

I will also try FMTDIR. It was my understanding it did not make a difference, but hell, I am open to anything by this point.

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