jaclaz

Member
  • Content count

    17,820
  • Joined

  • Last visited

  • Days Won

    99

jaclaz last won the day on February 16

jaclaz had the most liked content!

Community Reputation

801 Excellent

3 Followers

About jaclaz

Contact Methods

  • Website URL
    http://jaclaz.altervista.org/

Profile Information

  • OS
    none specified
  • Country

Recent Profile Visitors

6,033 profile views
  1. Redistribution permissions must have changed lately .... jaclaz
  2. And this confirms how each situation/experience/report may well be different ... ... and unfortunately there are no certainties jaclaz
  3. At the time it was debated, as there were contrasting reports, personally I would do it, it is not particularly difficult or problematic (the tricky part is making contact with the board powered on when removing the insulating strip). Compare with what is in the actually recommended guide: http://www.msfn.org/board/topic/133387-debricking-the-seagate-drives/ jaclaz
  4. Check also the ReadMeFirst and the FGA's: http://www.msfn.org/board/topic/143880-seagate-barracuda-720011-read_me_first/ http://www.msfn.org/board/topic/147532-fga-for-the-seagate-720011-drives/ Basically the BSY is a symptom which - at the time - was caused often by a bug in a given firmware revision, there may be tens of reason why the same symptom appears on that same or another firmware revision. The "fix" is to be considered more as a sort of "generic reset" than anything else, the idea is that - for whatever reasons - at power on the disk drive enters a sort of loop and through the procedure you attempt to force it to exit that loop. It is hard to say what the probabilities of success are in your case (or in any other case), as to actually diagnose what the cause of the BSY is there is the need of tools (and knowledge) well outside the reach of "hobbyists". The good news are that the risk of further reducing the probabilities of recovery by applying the reset are - from the reports - very little, i.e. if the procedure is applied correctly in the worst case it won't solve the problem, but it shouldn't "damage" the disk drive, a professional with the right tools and knowledge should manage to recover the same amount of data (if data is recoverable) no matter if he/she is given the drive now or after a failed attempt to resolve the BSY status. Still data is important, d@mn important, so it is only up to you to judge if the attempt should be made, I can offer no guarantees whatsoever. jaclaz
  5. Oww, come on. What do you think I could have used in 1995-1997? Quick timetable: Windows 3.11 = 1993 Zip disk=1994 Windows 95=1995 NT4.0=1996 Superdisk=1997 (and for whatever reason didn't really come to Italy before late 1998 or so, and they were very expensive, whilst Zip disks were common, relatively cheap and - I believe the SCSI ones at least, the parallel port ones were slow as molasses - much, much faster than superdisks) Both however soon became obsolete by 1999 or so, replaced by CDRW's, though I have used IDE/ATAPI ZIP disks up to 2004 or 2005, as they were just perfect as removable backup solution for a specific setup I had (DOS based) that used between 70 and 90 Mb of data. JFYI: http://www.hardwarecentral.com/showthread.php?42546-Zip-vs-Superdisk-(LS-120) jaclaz
  6. Not really a "floppy". Once upon a time, we are talking more than 20 years ago, the SCSI bus/protocol existed, which was at the time the fastest available (usually through an add-on card, typically Adaptec) for hard disks, and among the SCSI devices, there were SCSI ZIP drives and disks, 100 Mb in size, JFYI: https://en.wikipedia.org/wiki/Zip_drive https://www.win.tue.nl/~aeb/linux/zip/zip-1.html jaclaz
  7. As a side-side note I have run NT 4.00 for years on 2.1 Gb disks just fine (and they were the fourth upgrade, starting from 300 Mb. then 500 Mb and then 1.2 Gb). A typical NT 4.00 installation is/was around 150 or 180 Mb, HECK! with just removing the help files and a bunch of unneeded stuff I had it running off ZIP disks. Windows 2000 install grew to around 650 Mb (triple) and XP as well almost tripled that with a standard install size of around 1.5 Gb, so roughly XP is 9 (nine) times the size of NT 4.00, but a not too reduced system can fit into 500-800 Mb, maybe 1 Gb, so a 2GB SSD for just the system and a few programs (with data and possibly large programs on another mass storage device) is IMHO still adequate.
  8. @waltah Another possibility is to attempt (since you have it working on another machine) to attempt a move: http://www.michaelstevenstech.com/moving_xp.html Still the suggestion to use Fernando's latest drivers is a good one, and - besides - if your BIOS allows "IDE Compatibility mode", installing the XP without any SATA driver and "switching" to them later is possible, not easy-peasy but possible: jaclaz
  9. The benefit of what? The OP has a given PC and a given type/model of SSD's (of limited size). He has issues with the specific install (though he succeeded with similar hardware). You posted a oneliner suggesting him to buy another (bigger sized) SSD, something that seemingly doesn't address the base questions: 1) WHY the setup doesn't work? 2) HOW can I try to find what is the issue? (and hopefully solve it) Of course similar advice can be found all over the internet, typically, still one-liners: 1) buy something else 2) that is not possible 3) upgrade your (hardware, OS, software, whatever) to a newer version etc. And this right after the OP praised the MSFN forum for providing "more good advice" than the rest ... jaclaz
  10. Are you trying to make an example of the kind of support/advice that can be easily found outside MSFN? @waltah From what you describe it seems like a driver issue , or maybe a timing problem. Since you are using a FAT32 volume anyway, I would try (on a 16 Gb SSD) to attempt installing the XP from DOS (actual DOS) via WINNT.EXE, so that we remove one of the variables (the CD loading), see (only seemingly unrelated): Method description (via Wayback Machine): http://web.archive.org/web/20080302101935/http://www.911cd.net/forums//index.php?showtopic=16713 Also are you sure that the (I believe needed) SATA drivers are integrated into the source? (or are you installing in IDE compatibility mode? For the sake of testing I would try a surely UNtouched source, even if it doesn't actually install it may porovide some hint on where the process has issue). jaclaz
  11. You can find *anywhere* a full description of a MBR. Briefly: The MBR contains a partition table. The partition table contains four entries, each 16 bytes. Each entry describes a partition and contains 4 set of fields (not in this order) check any partition table description: 1) boot/no boot (i.e. hex 80 or hex 0) 1 byte 2) partition ID (1 byte) 3) CHS data, two fields, one describing the start address and one describing the end address, CHS addressing is nowadays obsolete, but it takes anyway 8 bytes. 4) LBA data, two fields, one describing the start address and one describing the number of sectors, each field is 4 byte, and as such it can at the very most represent 2^32-1=0xFFFFFFFF or 4294967295 sectors. Thus the limit is: 4294967295*512=2,199,023,255,040 bytes A good question would be what happens if one creates on a (512 bytes/sector) hard disk two partitions, one starting on LBA 2048 and extending for (say) 4294967295-2049=4294965246 sectors and a second one starting on LBA 4294967294 and extending for 4294967295 sectors? Would this move (with the limitation of the two partitions) the limit by another 2.2 Tib? jaclaz
  12. Maybe easily, but not "common", I believe you are the only one I know that uses one of such arrays. Maybe other people have not the knowledge or cannot afford a similar setup, which even today is not exactly "cheap". jaclaz
  13. JFYI, a reborn ZX80 (using only discrete components, unlike the ZX81): http://blog.tynemouthsoftware.co.uk/2016/12/minstrel-zx80-clone.html jaclaz
  14. Yep, but overall it is more than anything else some misinformation and/or outdated info due to the accumulated information on technology that changes (the hard disk hardware) under a "static" piece of software (the Operating System). At a given date the 2^32-1 sectors limit did imply that the max capacity to be around 2.2 Tb because *all* disks were 512 bytes per sector. Soon after the hard disk manufacturers found a possible way out by using bigger sector sizes, but in the meantime, due to the "transitioning" via the so-called "AF" drives (that I believe different manufacturers, besides calling them with different names also implemented slightly different) and to the remaining problem (no support for booting from larger than 512 bytes sector disks in most OS's) the piece of info remained valid. After all, imagine the fuss that would have happened if someone bought a - say - 3 Tb drive only to find out that it was either (512 bytes or AF) not fully accessible or (4Kb) not bootable, I can understand why it was simpler for the manufacturer not to make the distinction, particularly when the good MS guys were trying all they could to ditch MBR in favour of GPT (and BIOS in favour of EFI/UEFI). The ironic part (as I see it) is that in the meantime SSD's became the *standard* or *almost standard* main boot (internal) devices and they are still - after several years - nowhere nearing the 2.2 Tb size limit, and they are all (or almost all) emulating the 512 bytes sector size anyway. jaclaz
  15. The limit is not in "cluster" size (that is a characteristic of the filesystem), it is "sector" size (that is a characteristic of the hardware). Besides that, there are issues in a number of OS in booting from a non 512 bytes sector size hard disk drive (which does not affect obviously "data only" disk drives). It is not however really a "hoax", the two things belong to different times, the number (of sectors, not clusters) limited by the 32 bit address space in the MBR partition table came out earlier, at a time when disks were still mostly or very largely 512 bytes sectored only and had not actually reached if not maybe in high end disks the 3 terabyte size, and while the disk makers started making the 4k sectored disks (that effectively "move" further the issue to around 16Tb) Microsoft decided to not update existing OS to handle the matter and jumped on the (Intel driven) UEFI/GPT bandwagon (and to mostly 64 bit). In other words, until the disks were 512 bytes sectored the limit was there and it was not solvable, and when later it became solvable it was decided by MS to not fully solve it on MBR scheme and adopt GPT (forcibly coupling it with UEFI without any real technical reason) and the disk manufacturers didn't want (or couldn't) provide support for that. And coupling disks with USB enclosures may provide "funny results", JFYI: jaclaz