• Migrating image from 1990's IDE

    From antonp@gmail.com@21:1/5 to All on Sat Apr 4 14:59:09 2020

    TL;DR: Need help cloning a 90's-era LynxOS disk image, as the OS seems to require an exact CHS geometry match.


    I have a 1990's era woodworking CNC (Biesse Rover 322), which has a 2162Mb IDE HDD (Fujitsu MPB3021AT, 40-pin IDE with 4470C, 15H, 63S). See http://www2.fcpa.fujitsu.com/sp_support/ext/desktop/manuals/mpb3xxxat-manual.pdf

    The PC is a Pentium 133 with 64Mb of RAM. The POST screen mentions both Superpath (tm) BIOS Version 2.0 as well as Apricot VT BOIS Version 7.07, 9th June 1997.

    This machine runs LynxOS V2.3.0.

    I realised that the HDD was a likely failure point, and imaged this disk not long after I took ownership of the machine (2-3 years ago). I experimented with restoring the image to a number of similar-vintage disks (all 3-5 Gb but with different CHS
    geometry), but none would boot. (I cannot recall the exact error message, but it was basically just a BIOS-generated 4-5 digit number (no text). Googling for it basically said "Could not boot drive" or similar, so it wasn't even getting off the ground.)

    I was then able to source an identical Fujitsu HDD off Ebay in Germany - this cloned and booted just fine.

    A couple of weeks ago, when the original disk failed, it was a big relief to be able to replace the HDD and get going again in an evening, rather than ending up with a 3 tonne paperweight.

    I understand the gist of CHS (the Surepath/Apricot BIOS also seems to support LBA) but where I get hazy is in the actual cloning:
    1) If I have taken a clone image of the entire disk, does that or does it not depend on drive geometry? ie. I would expect that the image is a logical copy of the drive, rather than being CHS dependent?
    2) Or perhaps it is that LynxOS is attempting to address the drive "directly" and when the geometry is different, it is somehow not finding the data in the correct location?

    My concern is that my "new" drive is still 20+ years old, so who knows how long it will last.

    I would like to replace with a DOM type system, perhaps: https://www.ebay.com/itm/4GB-DOM-SSD-Replace-Vintage-3-5-IDE-Drives-with-this-40-PIN-IDE-SSD-Card/254364506542 (8146 Cylinders 16 Heads 63 Sectors)
    https://www.ebay.com/itm/16GB-SSD-DOM-Replace-Vintage-3-5-IDE-Drives-with-this-40-PIN-IDE-SSD-Card/312774694344 (16383 Cylinders 15 Heads 63 Sectors)

    What confuses me is that these CF DOM modules state that they present as a certain number of cylinders, heads and sectors in non-LBA mode. I would have thought this might be configurable on the module. ie. why is the 16Gb modules 15 heads, 63 sectors (so
    probably compatible with my drive, since I am told that the cylinder number doesn't matter if it is larger) but all 4Gb and smaller modules on Ebay seem to different, ie. 16 heads, 63 sectors?

    I am obviously not understanding what is going on, but I would have thought that the data on the CF card would not have actually changed, just the way it is presented by the IDE controller?

    Ultimately I intend to purchase something like the following, as I already have some 8Gb CF cards. However the ad says nothing about how the drive presents, or whether the CHS is configurable.

    I see in my research that different CF cards actually present different CHS values - I had no idea they used this format. Is there a way I can reformat them to the required CHS to match my existing image? Or am I going down the wrong rabbit hole?


    The first point of my question is I am struggling to understand how the super specific HDD is affecting me, i.e. is the operating system possibly trying to address specific CHS locations? I suppose it might be messy and complicated, but I almost find
    myself wondering whether that is just a case of manipulating the data in my image before I write it to a different HDD. (ie. something like inserting a 512-byte block of DEADBEEF after every 15 blocks, to pad it out to 16)

    The second point was to figure out how these DOM modules work (or possibly how the CF format works), and whether they are able to present as different CHS values, since the two near-identical ebay links I posted had different numbers of heads.

    I have no ability to reinstall the proprietary operating system and control programs from scratch either, so any solid-state or legacy solution needs to utilise my existing image, if necessary by converting the data blocks in some way. Biesse Inc. are
    not much interested in supporting 20yo obsolete technology, and basically recommend that I upgrade to a new machine.

    I have ordered one of the CF-to-IDE adaptors, so I will likely be seeing that error again soon.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)