jaclaz

I guess all you may get is my "standard reply #32": http://reboot.pro/2587/ Seriously now, how can you expect that we know what you are up to? Please, post some meaningful info, EXACT DETAILS of what you want to achieve, EXACT description of the files involved, etc., etc.. This way you will probably get back some meaningful help/advice. jaclaz

You've probably have this part "wrong". There is NO sign whatever on the referenced seller/item page whether this particular adapter: needs to be powered at 3.3 V or at 5 V actually outputs 3.3 V TTL or 5.0 V TTL The above two are two VERY different things. #1 is the power you give to the thingy. #2 is the signal level that comes out of it. With the ONLY exception of the specific adapter mentioned in the read-me-first (sparkfun) that actually changes it's output TTL level depending on the level of voltage you power it with, ALL other "conventional" RS232 to TTL need to be powered at 5 V (powering it at a lower voltage may either work or not, but basically it is pointless) OR at 3.3 V (powering it at a lower voltage may either work or not, but basically it is pointless, as well as powering it at 5 V, which could also fry the thingy). Again, with the same ONLY exception as above, RS232 to TTL are EITHER: dual 3.3 V TTL AND 5 V TTL level adapters (and have a switch or jumper or different TX/RX terminals for the TWO different levels OR: single TLL level adapters, which can be: 3.3 V TTL OR: 5V TTL If you have the latter type it simply won't work. This said, if you had initially one behaviour and now you cannot reproduce it with the EXACT same settings it may mean: the adapter is toast ( I have rarely seen this happen because of UNDERvoltage, nor because of accidental shorts or the like, so I doubt it) the actual HD PCB is toast (as well highly unlikely unless it died for "natural causes as supplying it a 5 V TTL signal instead of the 3.3 V one was NEVER a problem, apart that it won't "talk" with the PC) you did not repeat in the same EXACT conditions as when you initially had the garbage, try again, make sure, double sure and triple sure you have correct baud rate,parity, etc. (please note that if - without the ground connected - you get gibberish BEFORE accessing the HD terminal with CTRL+Z it ONLY means that you are getting gibberish because you did not GROUNDed properly and it is in NO way a sign that the terminal was accessed, if you prefer it could be that you didn't get to the HD terminal BEFORE and had the gibberish and you cannot get to the HD terminal NOW but see nothing as the gibberish is prevented by the ground, i.e. exactly the same failure, one showing gibberish and one showing nothing) Suggested course of action: make sure the TTL adapter sends (and receives) signals at 3.3 V TTL level (and NOT at 5 V TTL level) - like ask the seller for the manual/datasheet/whatever make sure that the particular item you got is functional (you will need an oscilloscope or a poorman's one made from an audio card) Example: http://www.zeitnitz.de/Christian/scope_en IF everything is as it should be, check again the PCB, try with it completely detached (just to get to the terminal). IF anyhting it is not, your best option is to get a "proper" TTL 3.3 V level interface (if this is 5 V) or trywith another adapter. jaclaz

@dencorso I am posting here, though maybe it would be more pertinent to the "super-floppy" thread. If needed, please move it there. Just imagine: Q.: What do you use to create a FAT 12 or 16 formatted image of a floppy or volume? A: Excel. jaclaz P.S.: Consider this an early pre-release version , I need some willing tester and some suggestions for "common" formats to include/add. The "batch file" part is the one that may get a number of improvements, right now it creates a "truncated" image but the good thing is that it needs no "external" utilities (32 bit 2K or XP needed Vista and 7 should work allright also but NOT 64 bit) If we are allowed to use mksparse and fsz (and dsfi/dsfo) we could make images faster and, besides "truncated" also "sparse" and "full size" (the latter can be done even now with a few lines added to the batch). The spreadsheets are protected (with no password) to avoid accidentally change formulas/data, but you can unprotect them allright. Attachment removed, new version a couple posts below.

That was the scope of my comment. The problem with him (and many other) is that he is actually followed by lots of people, so his opinions (no matter if right or wrong) are often mistaken for facts (which sometimes are, sometimes are not). jaclaz

Just for the record, be aware that the reputation of Steve Gibson is not unanimously considered as that of a good cybersecurity researcher, though he usually has some good points, he tends to make them sound like "the ultimate truth" or "the absolute truth" and, more generally to over-emphasize anything he happens to find (or think he has found). http://attrition.org/errata/charlatan/steve_gibson/ The "old code" is better is " old news", sometimes it is true, sometimes it is not. The general point is that no hacker (unless a hacker -ethical or not - does it for the fun of it) will lose his/her time on finding security exploits on systems that are used by a very little number of people and that - generally speaking, of course no offence intended - hold no meaningful/valuable data. You could also say that the best thing MS did for security was to push XP and later Vista :ph34r:/7, thus drawing attention away from 9x/Me systems, thus making them more secure in practice if not in theory..... jaclaz

Hi jaclaz, I have test-installed Letter Assigner v1.2.0, but apparently it is not possible to assign under Win98SE the drive letter B: to the LS-120 drive K:, I got the err msg: "it is impossible to use letter B for any drive other then its current owner, because B: is one of several letters assigned to the single physical drive". Also, when I right-click in the Letter Assigner window on any of the drives displayed, I get the err msg "Letass32. The program has performed an illegal operation and will be shut down." Win98 crashes shortly afterwards and I had to reboot + fix lost clusters. Any other suggestions? Well, we tried. Being a "low-level" kind of utility VGA-Copy most probably accesses the drive letter in a non-standard way. What about good ol' SUBST? (though usually letter assigner works where SUBST doesn't) Another idea may be that of using grub4dos to exchange/map drives at BIOS level before booting DOS. Try booting to DOS, and run GRUB.EXE from it. http://code.google.com/p/grub4dos-chenall/downloads/list Type: find ( and press [TAB] Which devices do you have listed? (try with and without the LS-120 connected so that you can identify how it is seen) jaclaz

Try the attached. And still this belongs to the actual merging command ( which is yet to be written). jaclaz split_inf_6.7z

Would good ol' Letter Assigner do? Courtesy of Wayback Machine: http://web.archive.org/web/20080703012252/http://www.v72735.f2s.com/LetAssig/index.html jaclaz

Try lowering baud rate, like: jaclaz

Or maybe not?. jaclaz

Try the attached. jaclaz split_inf_5.7z

Ahmad , you need to first thing procure yourself some common sense (I know it is rare today, but with some effort it can be found ). Quick recap: you HD took a bad hit. if the HD was spinning at the time, your heads have most probably crashed, compare with: once a head crashes, it hits the disk surface, leaving a small dent/groove in it some little material from the head or from the platter normally comes loose when there is a head crash every time your disk spins some of this trash is either carried around by the head or head arm or spread by the air cushion (and may land on the platter when the drive spins off) it is VERY likely that the "bad area" will grow because of these debris making more "grooves" NO hard disk is EVER reliable, one that had a head crash is definitely NOT ANYMORE RELIABLE NOW logical errors can usually be fixed, mechanical ones CANNOT (and no, they don't heal by themselves) So, you are asking a partially senseless thing , you should go buy a new hard disk NOW. If, for fun, or experiment or whatever you want to keep that failed hard disk as secondary (or tertiary) backup storage, it may be OK, but keeping it in service as the ONLY, SYSTEM, drive is IMNSHO asking for troubles. In any case, BEFORE ANYTHING else, it is VITAL to check thoroughfully the disk with the manufacturer diagnostic utility. Unfortunately TOSHIBA does NOT provide an official utility, but usually the IBM/Hitachi or the Seagate Seatools work with them: http://www.carrona.org/hddiag.html To locate bad sectors, you can use Victoria allright, read a few posts starting from here: http://www.911cd.net/forums//index.php?showtopic=24161&st=567 jaclaz

http://reboot.pro/14/page__pid__133740__st__30 jaclaz

Sure , that was expected. (It was you that assumed that the geometry was the problem ) Too bad , you give up just when you were warming up! Anyway, you are welcome . jaclaz

That grub4dos version is SERIOUSLY outdated and BTW has also a number of bugs/limitations (though they do not probably apply to the tests you made), from history: 2009-10-16 Turned off int13/AX=4B01/DL=7F cdrom query which may hang on some machines. Commented out DMA code related to running via KEXEC. Implemented 64-bit int13 memdrive block moving code. 2009-06-20(r68) add (ud) device to access space created with fbinst. 2009-06-11 fixed a bug of missing assignment of ES and BX registers in int13_handler(asm.S). 2009-05-13 fixed size-wrap-to-0 infinite loop issue in grub_read()(disk_io.c). 2009-05-07(r67) resolved conflict between int10 stack and BIOS Data Area(grldrstart.S). 2009-05-03 fixed a bug in geometry_tune(grldrstart.S, asm.S). zw2312914 report. 2009-04-30 triple mbr without bpb also bootable as a floppy(grldrstart.S). 2009-04-26 added ending CHS calculation for partition entry in mbr of the triple mbr(bootlace.inc). 2009-04-25 bug fix in dd about device length calculation(builtins.c). 2009-04-24 save and restore GDTR in int13_handler(asm.S). 2009-04-06 accept partitions starting in the mbr track(probe_mbr, builtins.c). 2009-04-05 triple mbr floppy partition (fdX,Y) support for some USB BIOSes(disk_io.c). 2009-04-04 fixed partition table entries in the 2nd and 3rd mbr of the triple mbr(bootlace.inc). 2009-03-31(r66) 0.4.4 official release. 2009-03-28 removed the problematic global variable "i"; reduced one open-file step for configfile on cdrom. 2009-03-27 fixed memory overlap issue on "map --rehook". Don't even THINK of using anything older that 2009-10-16, which can be found here: http://reboot.pro/15038/page__st__1 (but I am attaching a copy of it, just in case) What one should really use nowadays - expecially if starting using grub4dos - is LATEST EXPERIMENTAL version, here: http://code.google.com/p/grub4dos-chenall/downloads/list or however a decently recent enough version, suggested is 2011-04-29. jaclaz grub4dos-0.4.4-2009-10-16.zip

Yep , from the mouth of the wolf : Some additional reference: http://www.robvanderwoude.com/ntregistry.php http://support.microsoft.com/kb/301423/en-us jaclaz

Are you sure? You need the reg.exe in the 2K support tools (or at least this what has been always used). But you can use REGEDIT.EXE allright manually. jaclaz

No, it doesn't matter on which PC you attempt the recovery, as long as you use in TESTDISK the right geometry. The PHYSICAL geometry of a hard disk (this hard disk particularly) is 255 heads. From the screenshots you posted TESTDISK has it as 240 heads. See: CHS 96901 240 63 So, from what I can say from a distance it is "your "computer that has it "wrong" and on "her" computer geometry is 255 allright. (unless you ALREADY modified data on the disk, if this is the case, cannot say) Let's take first partition as an example. it has 31457280 sectors and starts at 0/32/33, so: (0*240*63)+(32*63)+33-1= 2048 <-start LBA 2048+31457280= 31459328 <- End LBA 31459328/240/63=2081 31459328-(2080*240*63)=9728 9728/63=154 9728-154*63=26 Geometry with 240 heads 2080/154/26 But: (0*255*63)+(32*63)+33-1= 2048 <-start LBA 2048+31457280= 31459328 <- End LBA 31459328/255/63=1958 31459328-(1958*255*63)=4058 4058/63=64 4058-64*63=26 Geometry with 255heads 1958/64/26 jaclaz

You have an "added difficulty". One of the two systems has a "non-standard" 240 heads geometry. As an example this is typical of a Lenovo laptop (but many "HP" desktops do the same). If you connect a hard disk internally, the BIOS "assumes" or "forces" the CHS geometry to be n/240/63 (whilst the "real" hd geometry is m/255/63. Since the disk is originally partitioned/formatted on that motherboard, the partition table and PBR/bootsector BPB will reflect the 240 heads geometry. When you connect the same hard disk to another "normal" motherboard (or even to the same motherboard but through an USB enclosure/interface) the geometry returns to a 255 heads one and you have problems in: booting running disk utilities (or viceversa, original was 255 and "current BIOS" reads 240, this seems like the case at hand). TESTDISK has an option to adjust geometry (perceived by TESTDISK). Right now it seems like: the current NTFS BPB has a 255 one the partition table (or the hard disk BIOS data) are 240. Try checking the geometry TESTDISK currently uses and change it to the "other" one, in your case the disk is seen by testdisk as 240 whilst it should be set to 255.. Then re-run the scan for partitions. For the record: The partition labeled "PQSERVICE" is usually a recovery partition, typical of most "BIG" OEM's like HP; COmpaq, Dell, etc., if I recall correctly "PQSERVICE" is used by Acer, Gateway and Packard Bell, but many other makers may use it) The "E" is the Extended partition. The "L" is the Logical volume inside it (with label "[DATA]). Since you don't need them, if you don't know what an Extended partiton is, it's allright. jaclaz

NOone is telling you to load the .iso in memory, we are all suggesting you to map the .iso directly, i.e. WITHOUT using --mem mapping. jaclaz

Do you think we are magicians or what? You cannot load an image in memory if you haven't enough of it. The scope of this app is to Install Windows from USB (and NOT to add to it every possible kind of OS, and NOT to twealk the latter to work -if possible - on underpowered machines) You may have better luck with Sardu or Xboot (or any of the other good LInux utilities): http://reboot.pro/forum/100/ http://reboot.pro/forum/126/ or do your own experiments, since this app already installs grub4dos, add the whatever you want manually, after WinsetupfromUSB has run: http://reboot.pro/forum/66/ Some examples of known working OS's: http://reboot.pro/5041/ Remember that if you map a .iso directly the .iso needs to be contiguous. jaclaz

That is NOT a problem, add: Still waiting for the "fake" problematic .inf .... jaclaz

Yes, the ISO standard allows for "links". Basically a "same file" (same name and same size, and probably also same CRC32) if found in the source tree more than once is written to the .iso as follows: first occurrence is the actual file every other occurrence is a link to the first file Since a link only occupies a few bytes, this allows for having all duplicate files fit in roughly half the size (or 1/3 if triplicated, etc.). I am not familiar with Easyboot, you may want to review it's help /docs or ask on it's forum: http://www.ezbsystems.com/cgi-bin/ikonboard.cgi jaclaz

No, meaning that it is NOT confirmed (nor will be). For *any* reason the partition table (or something else) has gone or is invalid, you need to run recovery oriented software to first thing try rebuilding the parition table and filesystem and, should this not be possible, use file-based recovery. A similar/related thread: If you need help for the recovery start a NEW thread. jaclaz

You can use ISO links (or graft-points) or "duplicates once". It depends on which software you use to build the .iso. Some reference: http://reboot.pro/9446/ jaclaz