jaclaz

Maybe you need to use devcon (no idea if it works on 10 or 11), on older systems it was the only tool capable of re-starting some devices without reboot: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-examples We have a copy re-compiled from the original MS source code here: but possibly you will need a neer version from the WDK: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon# jaclaz

There worm drive: https://en.wikipedia.org/wiki/Worm_drive https://www.imdb.com/title/tt0072431/quotes/qt0484648 jaclaz

Is it the same (13 pin) as this one? (this is attributed to the VL5) https://pinoutguide.com/Power/hp_vectravl5_power_pinout.shtml jaclaz Edit: Here is picture of the actual connector: https://h30434.www3.hp.com/t5/Desktop-Hardware-and-Upgrade-Questions/HP-Vectra-486-33VL-PSU/td-p/7970352

There is no mountain, OP is in a climbing gym. As long as there is awareness.of the futility, it's alright. Still, floppies are not a good substitute to recreate the ZIP disk experience, and it is not like your friend played with floppy disk images in a VM. A small gift for your friend, zippier: https://www.flickr.com/photos/dvsjr/albums/1489687 jaclaz

Not to be more grumpy that usual, but then your project makes no sense whatever. If you don't have the actual hardware AND some very valid reasons to use ZIP disks, there is not any reason (if not some peculiar form of masochism ) to choose a format (the ZIP disk) that is poorly documented, terribly supported by the various (real or virtual) BIOSes, and cannot be re-used by anyone else (if not in a VM) unless these other users have the actual hardware (and BTW something developed in a virtual environment very rarely will run on real hardware without changes). Just use a "normal" disk image, make it 100 Mb or so if you like the challenge of using a small size system. jaclaz

"Zip disk" is meaningless in the context of "drivers". There used to be 5 (at least[1]) ZIP disk drives, with different interfaces (and obviously difference drivers were needed for them): 1) Parallel <- normally NOT bootable 2) SCSI 3) IDE 4) ATAPI (almost same as above) 5) USB The "type the name of the command interpreter" error you are having (I presume it to be in text mode) is coming from the underlying DOS, it happens well before the Windows 95 (the GUI part) loads (and thus the needed drivers). Is the error you are having similar to this screenshot, right? https://www.betaarchive.com/forum/viewtopic.php?t=35451 If this is the case it is happening at a time when the boot is from the disk supported by the BIOS, no driver is needed/in use at this time. Either you have command.com missing or - for some reasons - the DOS cannot access the ZIP disk as C:\ (or as another drive letter, if it is not partitioned it may be A:\). This may have several reasons behind, a common one (but again it may depend on which specific Zip disk drive you are using) is the way the disk has been partitioned (ZIP disk "standard" was an active partition in fourth MBR partition table entry) or "not partitioned" (formatted as superfloppy), and in the specific BIOS you have and how it behaves in these cases, additionally ZIP disks used to have a "peculiar" CHS geometry, which may or may not be involved in the issue. It is also possible that again for *some reasons* the SYS.COM didn't transfer COMMAND.COM properly or it (or its directory entry) is corrupted. some related to ZIP disks info: https://www.win.tue.nl/~aeb/linux/zip/zip-1.html Maybe if you provide some details about the exact hardware you are using and the exact way you prepared the disk, a solution or a workaround could be suggested. jaclaz [1] a more detailed, though not necessarily complete, list is here: http://reboot.pro/index.php?showtopic=12436&p=108810

So it definitely is (was) something "queer" with the USB drivers you had before, and that now are probably either another set of drivers or re-initlalized/reinstalled. I have no idea if Windows 98 uses or can use "filter drivers" (like NT family, like the mentioned cfadisk, dummydisk, etc. ) what you reported might be related to one such filter drivers (installed and "paired" to either the whole USB subsystem or to that specific stick). Still in the NT world, there are similar enough reported misbehaviours with CD/DVD players due to (upper and lower) filter drivers related entries in the Registry, so it could have also been some Registry related issue, hopefully corrected by the sort of "reset" you did by disabling legacy USB in BIOS. jaclaz

Duel->Dual https://grammarist.com/spelling/dual-duel/ jaclaz

So the issue is not the BIOS (in itself) nor (probably) the USB drivers (in themselves) it is a combination of the two. Pure speculation, to be checked/confirmed: Case A, stick connected before booting: A1) when legacy USB is disabled in BIOS the OS knows nothing about the USB stick and when the drivers load they load/mount the device fully A2) when legacy BIOS is enabled in BIOS the stick is mapped by BIOS and when the USB drivers load they *somehow* load/mount the device partially Case B, stick connected after booting: B1) no matter if legacy USB is enabled or disabled in BIOS, the OS knows nothing about the USB stick until the drivers load and ... (either mount the stick fully or not) In theory A1 and B1 should behave the same, but there could be a difference between the USB drivers enumerating the stick when loading (case A1) or after having already loaded (case B1). jaclaz

FDISK won't allow anyway making more than one (primary) partition, the second can only be extended (with inside it one or more volumes), but it shouldn't crash on devices with more than one primary (i.e. it is another sign that *something* is "wrong" and specific to USB devices that are not BIOS mapped). jaclaz

Only for the record since 2010 (or was it 2007?) or so Office formats (.docx and .xlsx) are actually zip files, and of course android .pkg are also .zip files, as such the whole preamble is pure nonsense, then the article goes on to list a case in which the archive is encrypted and prompts the user to download a fake pdf that is a html that is a wrapper that prompts user to input a password to view the contents of the archive. Surprisingly the password is used to decrypt the archive. So many words to say: NEVER trust anything that comes from someone you don't know, particularly if it has an attachment, let alone an encrypted file that prompts you for decryption Besides the actual HP/Wolf report being largely useless for anything except some vague statistical data, I rarely happen to read poorly written articles such as this one, the Author cannot even cite the right percentage written in the report (that is 44% and not 42%) then suggests that all these archives behave like a few specific malwares (that represent only a minimal percentage of the malware delivered via an archive). jaclaz

RMPREPUSB (to workaround a similar issue in some BIOSes) creates (optionally) a second (very small, only one cylinder, and with a hidden ID, 21 if I recall correctly) partition, but that is intended for bootable sticks, if you see multiple partitions than *somehow* the MBR is read (though it is still possible that it is not "hooked"). To make a comparison, on NT systems, the known IMDISK driver (which should be called IMVOLUME, instead as it does not mount the disk, but rather the volume) "hooks" at a level "higher than disk manager/diskpart. Does FDISK see the disk? <- I believe that all other tools (including Partition Magic) have the same type of access as FDISK I don't think, in the case of USB attached to an already booted OS (I believe this is the case you are referring to), that there can be a workaround, as essentially the Windows 98 USB drivers "filter" whatever they want, if you actually boot from the USB stick, things should be different as the device is "mapped" by the BIOS. There could be (very likely limited to DOS, NOT to the GUI Windows command prompt) a workaround through grub4dos, if you can see when booting (even if booting from another device) the USB stick, if needed using the grub4dos USB drivers (aka usb --init) then the device would be BIOS mapped and (possibly, it has to be tested) available to FDISK in the DOS session, directly or though some form of remapping in grub4dos. Still the USB stick need to be connected before booting, so, even if it works it would be only a very partial workaround. jaclaz

Under DOS: SYS or FORMAT shouldn't affect the MBR anyway. FDISK should. It is very possible that *for whatever reasons* the drivers you are using mount only the volume (partition). How (exactly) are you using HxD? I mean, what are you accessing? If it is the drive letter then the MBR is not there, I don't know if under DOS/Windows98 there is an object similar to what the \\PgysicalDrive is in NT, the "Hard Disk n" in HxD seen here: https://thestarman.pcministry.com/tool/HexEds.htm I wouldn't be too surprised if your drivers or something else consider the USB stick a "removable" device and mount it only as "superfloppy", automatically "filtering out" the MBR and the sectors before the volume. jaclaz

The good question is why the original would BSOD. The "clones" may have issues (it depends on how exactly they were cloned but also how they were "managed", in the sense that if they were connected at the same time of the original you may be having issues with disk signature collisions). Almost any Windows PE will likely have issues with SCSI hardware, unless you build your own PE including the needed SCSI drivers. Boot sector analysis will anyway lead you nowhere, the issues you are having are not connected to possible bootsector issues. The 7b is due to some mis-configuration of the drivers (or of the BOOT.INI, which you seem to have corrected). The (Bios) boot sequence is: Bios->MBR->bootsector of active partition->NTLDR->BOOT.INI choices since you are loading the NTLDR and BOOT.INI, the bootsector is "good enough", as usually the two main possible issue with it are: 1) corrupted boot code 2) "wrong" geometry of device in the data and both will lead to different errors, like a hung boot with a flashing cursor (or a J or a G) on black screen, disk errors embedded in the bootsector like "Cannot fins NTLDR" or similar. The c000021a (and 0xc0000005 status) are more likely to be an issue connected to a mismatch in the Registry with a number of things, including disk signature, drive letter assignments, SCSI device ID's, in the case of (if I understand correctly) an external SCSI to SATA adapter for the SSD it could be also that the "adapter" is detected "differently" from a "native" SCSI disk. I am afraid there is little that can be done if even the "original" is not booting or gets a BSOD as you cannot use it as a reference to make comparisons and finding info online on NT 4.00 is very difficult these days. jaclaz

bbc.com redirects to https, that may be (part of) the issue. Try: http://info.cern.ch/ jaclaz

98 should work just fine on a USB stick, though it may depend on the hardware (motherboard), try following this, the only mod needed is MaxPhysPage value in system.ini and starting the setup with a particular set of parameters from DOS: https://www.youtube.com/watch?v=5Qd7cDbtwj4 setup /c /it /p a;b jaclaz

On BIOS, one of the things that "made a difference" was the presence of TWO (primary) partitions, If you check the RMPREPUSB, you will see how it has an option to make a second (tiny, one cylinder) hidden partition. It is possible (but not given) that even the UEFI implementation on those motherboards is sensible to it, even if the GPT should only have one entry in partition table (the "protective" one) there is the possibility to make a "hybrid" partitioning, with the added second partition entry, no way to know if it will do anything, of course. There is a nice page by Roderick Smith (author of Gdisk) about hybrid MBR's: https://www.rodsbooks.com/gdisk/hybrid.html There are other workarounds, check: http://reboot.pro/index.php?showtopic=12436 it could also be that the "removable" bit is actually meaningful in your specific BIOS/UEFI. jaclaz

Of course it depends on the specific stick controller AND on the specific BIOS. Most of the sticks have a setting (called in jargon "removable" bit) that can be "flipped" by the Manufacturer Tool. Whether a Manufacturer Tool is available or not (and if even minimal instructions/docs for its use exist) vary greatly on the specific make/model of the controller inside the stick. Sandisk (that you mentioned in your other post) is a known exception for two reasons, their tools never leaked (AFAIK) and their controllers are not programmable via the USB connector (as well AFAIK they have on the PCB some contacts that can - presumably - be used with a TTL or similar serial adapter). But - generally speaking - this "removable bit" does not in itself affect in any way the BIOS (and more generally "real mode") part of the booting, issues can happen later in the booting phase and/or in the way the OS behaves after booting. If the manufacturer tool is available and you have the guts for it (a mistake in using it may well make the device not working anymore) setting the stick as "fixed" is a good idea, but there are filter drivers for Windows that can make the "flipping" at OS level, historically a driver called cfadisk.sys was made (originally for CF cards) then a couple similar ones came out dummydisk.sys and its "reversed version" rdummy.sys (making a fixed device removable), the most recent one is diskmod.sys that offers some other features: http://reboot.pro/index.php?showtopic=9461 http://reboot.pro/topic/22249-diskmod/ Windows before 10 treated "removable" (USB) devices different from "fixed", i.e. the stick was either unpartitioned or - if partitioned - only one (first) partition would have been mounted/assigned a drive letter, so the filter driver was needed whenever multiple partitions were needed or wanted, one of the very few good things that Windows 10 did was to allow multiple partitions on removable media, so that nowadays cases where the filter driver is needed are rare. Anyway all the above has historically been irrelevant when it comes to "booting" (defined for the scope of this post as the initial part of booting, up to the choices in the boot manager configuration files). Problems in this early part usually derive from (not necessarily in order of relevance): 1) "wrong" HS geometry of the partitioning/formatting (almost anything partitioned under windows will be 255/63, which may or may not suitable) 2) errors in the MBR or PBR code or data 3) strange settings or quirks in the motherboard BIOS, including (but not limited to) "allergy" to specific MBR code, limits on geometry depending on size of the device, device size limits, and more, like needing two partitions on the stick The above is about BIOS/MBR, I hate to say this but (with some exceptions) UEFI booting often has less issues as it does not usually suffer from #1 and #2 above. You will need to describe the issues you are having and the specific sticks and motherboards involved (and of course the boot manager/OS you are trying to boot). jaclaz

Maybe the issue is "elsewhere", there is no reason why a "normal" USB stick (properly prepared/partitioned/formatted) should not be bootable. There is actually in the USB stick controller a "flippable" bit that can tell to the OS whether the device is "removable" or "fixed", but that does not change if it is bootable or not. The issue could be related to the motherboard BIOS/UEFI settings or (for whatever reasons) expecting something "particular". Is that MBR or GPT? And are you booting BIOS or UEFI? You could start a new thread, possibly here: https://msfn.org/board/forum/169-hard-drive-and-removable-media/ detailing the make/model of the stick, how you partitioned/formatted it, etc., and we could check it and (hopefully) find out a way to make it bootable (up to loading - say - the BOOTMGR and BCD ). jaclaz

https://www.doomi.ch/mtcp-tcp-ip-for-dos/ http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_mTCP http://www.brutman.com/mTCP/ jaclaz

Those are hex values, so - if they represent a readable string - they are somehow encoded/encrypted/transformed. There are like a zillion ways this could have been done, maybe - just maybe - if you provide some actual info (name/path of the key, what the value should represent, etc.) then someone might know which specific encoding is it. jaclaz

The motor is usually powered at 12V, very likely it can stand a 15-20% voltage increase, at 14.4 V it would probably reach 8,640 RPM, give or take 33 and1/2 tolerance. You can replace some 15-20 SMT components on the PCB board and write a new firmware for it. You only need 5-10 years in UNI+experience in hardware engineering, some 5-10 years in software development for embedded devices, another 5-10 years experience with access to hard disk manufacturers codebase, a semiconductor factory willing to create a new SMOOTH chip and you will probably have a working prototype. Ah, wait, before I forget, you will also need a soldering iron and a USB to TTL converter. jaclaz

Sure. https://en.wikipedia.org/wiki/Sleepwalking#Sleepwalking_as_a_legal_defense Better than "officer, the Devil made me do it...", still ... jaclaz

Fact is that noone really knows for sure, some versions are plausible. others not so much: https://unix.stackexchange.com/questions/6804/what-does-dd-stand-for jaclaz

dd (which is the shortening of copy and convert , don't ask [1]) is a traditional Unix/Linux command that simply copies bytes (or in the case of hard disks sectors/blocks) as they are. Of course there are several other programs that do the same, either command line or GUI. dd-like or "forensic sound" means that the output (be it an image or directly another device) is EXACTLY the same as the input, i.e. it is an EXACT, 1:1 copy. For whole disks, it means that the target image (or the cloned disk) is exactly the same size as the source, as it contains all sectors, unlike many (commercial) cloning/imaging tools that - in order to save time/space - either interpret the filesystem and only copy files indexed in it or (swiftly?) ignore already 00ed sectors in the source, usually adopting proprietary file formats for the images (an image taken with dd is usually called RAW as it contains nothing but the contents of the source, no headers, no footers, no checksums, etc.). About 1 or 0's it doesn't really matter, the 00 is a convention, new disks (usually) are all 00's, if you want to check at the bit level the values used are (normally) 55 and AA hex, i.e. 01010101 10101010 so that (in two passes) every bit is actually flipped. jaclaz [1] If you need to ask, and have some time, enjoy: http://reboot.pro/index.php?showtopic=15207