jaclaz

Then install syslinux to the stick and go the other way round, i.e. add BOOTMGR to the Syslinux menu. jaclaz

Oh, yes, I have it, I just inserted the plug in the motherboard socket and my Me detected the mouse allright. No need to start a new thread for my problem, it is already solved. My apologies to the OP for having temporarily hijacked the present thread. jaclaz

Yep, those are the data, clearly RPM senses the disk with 512 bytes/sector. 9,729 x 255 x 63=156,296,385*512=80,023,749,120 63+156299374=156,299,437 both CHS and LBA are more orr less correct (given the HPA region) All is well that ends well. Go slowly, come back quickly. jaclaz

I doubt that any number of piranhas or similar bombing tactics can do anything to my flying-submarine-tanks, but I don't think anyway this is the right place to proof that. In my basic English: the bolded part is enough to doubt that a Me problem goes here, additionally while looking to the previous posts to make sure I had the exact same problem, I noticed how the problem seemed like being connected with a Toshiba laptop and it's BIOS, so I think I will start a new thread for it, calling it: MSFN Forum> Microsoft Software Products> Windows 95/98/98SE/ME> How can I get a PS/2 scrolling mouse to work in Windows Me (no, not on a Toshiba)? If you want, if you have the same problem as mine, you could post on the new thread, and I will change it's title to : MSFN Forum> Microsoft Software Products> Windows 95/98/98SE/ME> How can I get a PS/2 scrolling mouse to work in Windows 98SE or Me (no, not on a Toshiba)? jaclaz

I don't care (much ) about the size. I asked about the geometry. With reference to this screenshot: Second line from top how many Mb/cylynders/heads/sectors does RPM see? At this point most probably values meaningful with a sector size of 512 bytes. jaclaz

As another suggestion (that will go unlistened to as before), you should not play too much with that kind of tools, you know, kids, matches..... Leave alone the HPA and forgive about the handful of sectors in it. The only important thing is that you managed to get Windows 9x installed. I would have appreciated a reply to the simple question I asked, but it seems like it's not my lucky day. jaclaz

I am having the same problem, only on Me. I am starting to think that I should actually connect the PS/2 plug on the mouse cord to the PC motherboard socket. Maybe I should start a new thread, since it has nothing to do with Windows 95 and this thread is specifically about Windows 95 and the problems in conjunction with a specific Toshiba laptiop model and it's Accupoint device..... jaclaz

Apparently YES , if you expect to have an IPL right after having Zeroed out a disk..... The disk is ALL 00's->the IPL is all 00's-> it is an "unknown" IPL (does it makes more sense now?) Can you post WHICH drive geometry RPM finds? You know, like in : jaclaz

Do you mean "found a .iso" or "found a .iso having bought a License for it"? The question is NOT so-slightly different. Your first step should be to make sure you are NOT using Warez releases. Be VERY aware of Rule #1.a: http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules jaclaz

A possibility: http://www.robvanderwoude.com/vbstech_ui_password.php http://www.robvanderwoude.com/vbstech_ui_changepassword.php This shoukd NOT work on 7, but may in XP64 : http://drbatcher.blogspot.com/2011/03/hiding-password-input-in-batch-files.html Are .com files supported in XP 64 bit? There is a possible way through ANSY.SYS usage: http://www.computing.net/answers/dos/how-do-i-hide-keyboard-input-in-a-batch-/7152.html or a near-solution using COLOR: http://www.dostips.com/forum/viewtopic.php?p=602&sid=3353dd3f344724a7645bcbb7f9533cc8 Using editv is more like it (still if we are talking of ".cmd" or "batch"): http://www.westmesatech.com/editv.html but see here also: jaclaz

Only too happy to have contributed to (yet another ) happy bunny : http://www.msfn.org/board/index.php?showtopic=128727&st=10 jaclaz

Actually on the thread DeadDude found (actually NOT that one, but near it ) : http://community.wdc.com/t5/Desktop/Physical-Sector-Size-different-between-WD20EARS-00MVWB0-and/td-p/218226 there is an interesting report. An advanced format drive (even if "internally" has 4 Kb sectors) should expose outside a 512 byte one. The XP alignment issue is seemingly only EITHER: jumper 7 and 8 -> add a fake sector so that XP Disk Manager starts first partition on sector 64 instead of 63 Advanced WD format -> simply a "modified" partitioner that uses multiples of 4 x 512 as addresses The thingy on VIsta or 7 is not needed as they will anyway normally start at 2048. This is consistent with the "scarce" literature available and with "common sense". It would be interesting to try partitioning such a drive under Vista or 7 with the Registry patched to respect cylinder boundary. The thread reports the fact that - probably due to a mis-configuration in the factory - the particular drive talked of there does not "expose" the right sector size. So it seems like this is possible, though I find very queer that it happens on such a smallish (for today's standards) disk size as 80 Gb. I would try contacting WD support, as what Deaddude bought was a disk with 156,301,488 sectors (of 512 bytes each). In the meantime can't you simply test BOTH RPM and Partition Logic and report which geometry they recognize? jaclaz

The WD utility will wipe anyway enough data, at the minimum first and last million sectors: You don't actually need to 00 out anything but the first (say) 100 sectors. Anything else is overkill, including the WD utility and ActiveKill disk. If you want to completely wipe a disk use the secureerase utility: http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml that will use the internal ATA commands and will be faster than *any* software based solution. @dencorso Comeon , you know better than suggesting to wipe a whole hard disk, and WHEN this is needed, to suggest anything but the internal ATA commands.... We have at least one report: http://reboot.pro/13601/ http://reboot.pro/13601/page__st__87 that a "same" 250Gb drive took 85 minutes vs. around 210 (using DBAN) It yould be interesting if you could do a comparison test of the ATA command and Active Kill Disk (dos extender) on any "spare" disk you may have handy. JFYI, a carpenter's comparison : http://reboot.pro/13601/page__st__46 @DeadDude The "advanced format" does NOT apply to your drive: http://www.wdc.com/global/products/specs/?driveID=770&language=1 as you can see you have 156,301,488 sectors, which multiplied by 512 makes roughly the 80 Gb. So that drive has "standard" sectors, not the "advanced format" 4 Kb ones. Some disk drives may have a jumper, but I don't really think that an 80 Gb one has them. WHERE exactly did you learn that your disk is "advanced format"? jaclaz

Yes this is by design The "Left Alt key" is actually the "Alt key," whilst the "Right Alt key" is actually the "ALT Gr" key, this is evident on some localized keyboard but not on all of them and NOT on the US one. http://en.wikipedia.org/wiki/Keyboard_layout jaclaz

Sure , it is an UNsupported utility somehow "leaked" from SanDisk techical support, called ATCFWCHG.COM. Before attempting to use it, I would rather see if either of cfadisk.sys or dummydisk.sys work on 2K (I seem to remember that I did test cfadisk.sys on 2k successfully). Post if you need links to either. jaclaz

Are you - by any means - suggesting that (apart form wear) a hard disk that has been "molested" by "having been NT partitioned" has some kind of "memory"....? Any actual comparison between the wear of a disk coming form a NT based machine used by a granny to just check e-mails once a week and one coming from a 9x gamer machine? About imaging, if you think that it is overkill most of the times, you are perfectly right , but if you think that (should you know where your towel is ) it is not a VERY comprehensive way to be able to re-create a working machine, you would be wrong. When you image a disk (dd-like or forensic sound) you have ALL the informations that were on the disk. From the ALL you can extract ONLY those that you need and/or modify them to suite your particular needs. Using ANY other method you only have PARTIAL info. If you got the "right subset" of the "ALL" in the "PARTIAL" it's OK (and you saved probably some time and definitely a lot of backup space ), but if - by any chance - you need something that is not comprised in the "PARTIAL" you are stuck. Everyone is - as always - free to take his/her chances, of course. A good substitute (IMHO) for RPM (which remains - if you READ the docs AND you know what you are doing, i.e. know how a partitioning scheme works - besides one of the "best" one of the "simpler" partition utilities) is -strangely enough - a tool developed completely outside the DOS/Windows/Linux world, PartitionLogic: http://partitionlogic.org.uk/ jaclaz

@dencorso 1) NO. The ECMA is the "right" approach. If you take some time around you will see that the actual sources for the 4078 are (directly or INdirectly) just: Norton, Peter (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN 0-89303-583-1, p. 157. Brian Jenkinson, Sammes, A. J. (2000). Forensic Computing: A Practitioner's Guide (Practitioner Series). Berlin: Springer. pp. 157. ISBN 1-85233-299-9. "...only 2^12 (that is, 4096) allocation units or clusters can be addressed. In fact, the number is less than this, since 000h and 001h are not used and FF0h to FFFh are reserved or used for other purposes, leaving 002h to FEFh (2 to 4079) as the range of possible clusters." or the Wikipedia article that cites those two. The good Linux guys evidently trusted this info: http://www.oldlinux.org/Linux.old/distributions/cnix/FAT.pdf but later, see here: http://www.win.tue.nl/~aeb/linux/fs/fat/fat-2.html they decided to use the "right" value 4084. I expected (and rloew quickly and kindly complied ) some experiments to be carried (I already did a few of them and a F0 through F5 gave no problem whatsoever). No matter how hard you (and Peter Norton and Brian Jenkinson ) stamp your feet, the statement/assumptions that values F0 and F5 are not usable/are reserved has been demonstrated m00t. On the other hand, it would be easy (for the ones that prefer following this myth) to change the 4084 and 65524 values in the two formulas that contain them, but it would be IMHO "wrong", and besides (notwithstanding) the trifling practical effect of having 6 more or less addressable clusters, it is "philosophically" wrong to perpetuate a mistake. By the same metrics, using ONLY 1.2, 1.44 or 2.88 images in El_Torito emulation CD's would be "safer", and making several passes to wipe a HD (all 35 of them) would be "failproof", and then I suppose we could all go home and start gardening as a hobby instead of this..... When (and IF) you (or someone else) will produce an image that gives problems under a "used" (in the sense of common) "recent" (in the sense of NOT a 1990 fork/rewrite of CP/M or SVR4) OS I will gladly modify those two values or provide a "switch" to toggle between 4084/4078 and 65526/65518. 2) Well, it's a "temporary sheet anyway, but thanks. 3) Sure, those are just 5 lines with the formulas to experiment a bit, those entered are just "random examples".... 4) This "max 512" or "max 32 sectors" for root entries may be interesting in the "future" main sheet, as a consequence of a switch like: format behaving as: DOS x.xx to x.xxx DOS y.yy to y.yy Windows 9x ... Windows NT/2K/XP/2003 Vista etc. FF6/FFF6 was never obiect of any doubt, it cannot be used. (last character in the previous sentence is a dot or full stop or "period" ) I don't get this : The temporary "clusters" sheet has been made in that form EXACTLY to avoid issues with "counting from" as it calculates ALL possible values and subtracts from them those that - for one reason or the other - cannot be used. As I see it, the next step (the one for which I need some help) would be testing a few "queer" sizes/combinatons on a "real" system and verify that the spreadsheet "simulation" is accurate. Comeon guys, use your fantasy, think about values that may create an issue, and test them... jaclaz

An update. Please find attached a .xls with the "FINAL" list of "known Floppy Formats". It would be appreciated if the values in them were checked by someone else than me. The real news (though probably very few people will appreciate the importance of them ) is that with some patience (and a couple mindboggingly complex Excel Formula's ) I have (hopefully) transformed the table/list from "static" to "dynamic", in the sense that the three fields: Sector(s) per FAT Sector(s) per Cluster Root Entries Are now calculated even for "known floppy formats" (and they actually seem like OK ). Checks, tests, opinions, etc. are welcome. In the spreadsheet there is also a "temporarily" added sheet about the 4078/4084 and 65518/65524 issue, after reviewing a bit the sources, it seems to me like the lower values are some kind of "myth" that perpetuated itself by cross-referencing sources (involving also the good Linux guys for some time ). My choice is to use ECMA 107: jaclaz P.S.: Attachment removed, current version attached to post #143

I am not sure to get it. You have a keyboard that has the numerical keypad BUT that hasn't the Numlock "led" or "light"? OR You have a keyboard that has the numerical keypad BUT that hasn't the Numlock key (top left of the NumPad)? OR BOTH the above? You can set/unset Numlock on via software allright: http://www.somacon.com/p339.php the above does not work on 0x/Me, the following should: http://www.softpedia.com/get/System/System-Miscellaneous/NumLock-SJ.shtml Or you can try nircmd: http://www.nirsoft.net/utils/nircmd.html (cannot say if the specific feature works in 9x/Me) jaclaz

@HoppaLong jaclaz

Happy to know that the issue - if not solved - has been at least found a reason why. It seems like Toshiba made really things much harder than needed, compare with: http://web1.toshiba.ca/support//techsupport/tsbs/all/-tsb000523.htm jaclaz

I don't get it. Care to explain/expand? Some docs on the Seagate Console surely good for 7200.11 (cannot say for 7200.12) are here: http://files.hddguru.com/download/Datasheets/Seagate/Seagate%20Diagnostic%20RS-232%20Port/ http://files.hddguru.com/index.php?action=view&filename=seagate%20diagnostic%20command.rar&directory=Datasheets/Seagate/Seagate%20Diagnostic%20RS-232%20Port& jaclaz

Something like this? http://jacquelin.potier.free.fr/ShortcutsSearchAndReplace/ But wouldn't it be easier to use an approach like: http://community.spiceworks.com/scripts/show/298-change-shortcut-lnk-target-paths-in-bulk You can also try with just copying shortcuts and then "fix" them, using this one (that supports command line): http://www.nirsoft.net/utils/shman.html but cannot say what happens with "name conflicts" or how fast/convenient it can be. (I mean are we talking of tens, hundreds or thousands .lnk files?) jaclaz

@ppgrainbow Not to be more grumpy than usual (trying to as grumpy as usual ) BUT WHAT THE HECK are you doing? I mean, your last post you were unable to install a new driver for the mouse due to a conflict of unknown nature, what happened next? Can you see how between these: SOmething must have happened or you may have somehow a "mixed set" of drivers installed. Rest assured, you did NOT : I am eager to understand how you can press a button up Have you got an actual picture of the actual Mitsumi mouse? Is it like this one? http://www.ebay.com/itm/MITSUMI-STANDARD-SCROLL-MOUSE-PS-2-NEW-free-shipping-/370122564086 jaclaz

Are we talking of OEM or ANSI? http://www.irongeek.com/alt-numpad-ascii-key-combos-and-chart.html or "windows encoded"? http://msdn.microsoft.com/it-it/goglobal/bb964658.aspx Could it be the Registry? http://en.wikipedia.org/wiki/Alt_code (but that should be only for ANSI/UNICODE, i.e. the ALT<+>+<xxxx> method) jaclaz