Image Map Image Map
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 31

Thread: Seagate ST-4053 and IBM AT

  1. #21

    Default

    1790 sorry
    IBM PC 5150(A): IBM PC 5150(B): IBM PC 5160 (64-256k): IBM PC 5160 (256-640k): IBM PC 5170 (099): IBM PC 5170 (319/339): IBM PC 5140: IBM PC 5162: IBM PC 5155: IBM PC Expansion Unit 5161:
    WANTED!: IBM 5175 monitor, IBM 5145 monitor, IBM PC/XT/AT rear screws, Intel INBOARD 386AT card, IBM 5140 keyboard, very early IBM PC (S/N: under 5000)
    My IBM PC hardware collection

  2. #22
    Join Date
    May 2006
    Location
    Melbourne, Australia
    Posts
    6,484

    Default

    Quote Originally Posted by romanon View Post
    Ok I dont want to LVL format it agin because now disk is stable and full of dates, but when I switch now to type 17, I get error 1780 on startup.
    Quote Originally Posted by modem7 View Post
    1780 or 1790 ?
    Quote Originally Posted by romanon View Post
    1790 sorry
    I have a fully functional IBM 5170, fitted with a type 2 drive, an ST-4026. If I change the hard drive type number in SETUP from 2 to 3, then restart the computer, I see (after a minute or so) a 1790 error.

    Type 2 = 615 cylinders / 4 heads
    Type 3 = 615 cylinders / 6 heads

    One of the things that the 5170's POST does, is a read of the last track (track = combination of cylinder and head). And so after changing the type number to 3, the POST tried to read CYL=615/HEAD=6. Obviously that fails for my four-headed ST-4026, and the POST generated the 1790 error (one of many causes of 1790).

    Regarding your ST-4053 and the 1790 error that results when you set type 17 (977 cylinders / 5 heads). Could that be because CYL=977/HEAD=5 is unreadable on your ST-4053 ! You should be able to check that via SpeedStor.

  3. #23

    Default

    But dont forget to fact, that disk is working without any problems on 386 computer with 1024/5/17 parameters. So I assume, that disk is OK.
    IBM PC 5150(A): IBM PC 5150(B): IBM PC 5160 (64-256k): IBM PC 5160 (256-640k): IBM PC 5170 (099): IBM PC 5170 (319/339): IBM PC 5140: IBM PC 5162: IBM PC 5155: IBM PC Expansion Unit 5161:
    WANTED!: IBM 5175 monitor, IBM 5145 monitor, IBM PC/XT/AT rear screws, Intel INBOARD 386AT card, IBM 5140 keyboard, very early IBM PC (S/N: under 5000)
    My IBM PC hardware collection

  4. #24
    Join Date
    May 2006
    Location
    Melbourne, Australia
    Posts
    6,484

    Default

    Quote Originally Posted by romanon View Post
    But dont forget to fact, that disk is working without any problems on 386 computer with 1024/5/17 parameters. So I assume, that disk is OK.
    But maybe the POST in that 386 does not try to read the last track. The POST authors do not need to copy IBM.

    And DOS is probably not going to write/read that track until the drive has been almost filled with data.

  5. #25

    Default

    Quote Originally Posted by modem7 View Post
    But maybe the POST in that 386 does not try to read the last track. The POST authors do not need to copy IBM.

    And DOS is probably not going to write/read that track until the drive has been almost filled with data.
    I dunno about that.

    IIRC, DOS is or at least was predisposed to sequentially write to the disk until it reached the end of the disk. Holes left by deleted or replaced files were skipped over until the end of the disk had been reached. Only then were the previously created empty spaces filled with data. E.g., if you deleted a large file on the disk, all that empty space would remain empty until the remainder of the disk had been written to. Only then would DOS write to those previously written areas in the middle of the disk. This 'feature' actually made it possible to easily and successfully recover previously deleted files since there was no overwriting of their data areas until the rest of the disk had been completely filled. At that point DOS would go back and begin filling the 'Swiss Cheese' with data. Optimizing the disk, thereby eliminating the 'Swiss Cheese' effect, would prevent DOS from reaching the end of the disk until the disk was actually full as well as remove the possibility of recovering those previously deleted files.
    PM me if you're looking for 3" or 5" floppy disks. EMail For everything else, Take Another Step

  6. #26
    Join Date
    May 2006
    Location
    Melbourne, Australia
    Posts
    6,484

    Default

    Quote Originally Posted by Stone View Post
    IIRC, DOS is or at least was predisposed to sequentially write to the disk until it reached the end of the disk. Holes left by deleted or replaced files were skipped over until the end of the disk had been reached. Only then were the previously created empty spaces filled with data. E.g., if you deleted a large file on the disk, all that empty space would remain empty until the remainder of the disk had been written to. Only then would DOS write to those previously written areas in the middle of the disk. This 'feature' actually made it possible to easily and successfully recover previously deleted files since there was no overwriting of their data areas until the rest of the disk had been completely filled. At that point DOS would go back and begin filling the 'Swiss Cheese' with data. Optimizing the disk, thereby eliminating the 'Swiss Cheese' effect, would prevent DOS from reaching the end of the disk until the disk was actually full as well as remove the possibility of recovering those previously deleted files.
    That is not how I am seeing IBM DOS 3.3 behaving (as observed via the 'block' map in Norton Speed Disk).

    I expect that over the years, Microsoft adjusted the cluster allocation algorithm. In the days of DOS 3.3, Microsoft may have been prioritising performance due to the relatively slow head seeking speeds of the time.

  7. #27

    Default

    Quote Originally Posted by modem7 View Post
    That is not how I am seeing IBM DOS 3.3 behaving (as observed via the 'block' map in Norton Speed Disk).
    If you actually use Speed Disk to optimize the disk you are, in fact, performing the action as described below:
    Quote Originally Posted by Stone View Post
    Optimizing the disk, thereby eliminating the 'Swiss Cheese' effect, would prevent DOS from reaching the end of the disk until the disk was actually full as well as remove the possibility of recovering those previously deleted files.
    ... and once you do this all bets are off as this resets the disk to a 'zero state', as if it were unwritten to.
    PM me if you're looking for 3" or 5" floppy disks. EMail For everything else, Take Another Step

  8. #28
    Join Date
    May 2006
    Location
    Melbourne, Australia
    Posts
    6,484

    Default

    Quote Originally Posted by Stone View Post
    If you actually use Speed Disk to optimize the disk you are, in fact, performing the action as described below:
    If one starts Speed Disk, then chooses not to perform the optimise operation, then Speed Disk shows the current block map (distribution of used and unused cluster blocks).
    One can then exit to DOS, create/copy files, then do the above again to see how the block map has changed.

  9. #29

    Default

    Quote Originally Posted by modem7 View Post
    That is not how I am seeing IBM DOS 3.3 behaving (as observed via the 'block' map in Norton Speed Disk).

    If one starts Speed Disk, then chooses not to perform the optimise operation, then Speed Disk shows the current block map (distribution of used and unused cluster blocks). One can then exit to DOS, create/copy files, then do the above again to see how the block map has changed.
    What type of HD are you using? MFM or RLL? Something else?
    PM me if you're looking for 3" or 5" floppy disks. EMail For everything else, Take Another Step

  10. #30
    Join Date
    May 2006
    Location
    Melbourne, Australia
    Posts
    6,484

    Default

    Quote Originally Posted by Stone View Post
    What type of HD are you using? MFM or RLL? Something else?
    It is MFM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •