Beta of Ami (early Windows word processor) on eBay

[xelloss]

This might be of interest to somebody:
AMI Pre-Release (1988)

[thunderbird32]

Well, I bought it. Hopefully the discs still work. I've recently bought a Kryoflux, so I should have a pretty good chance of getting solid copies.

[mrpijey]

Awesome! Maybe we can preserve one more rare beta .

[thunderbird32]

This just came in today. Hope to get it imaged and uploaded before the end of the week (the imaging is the easy part, it's scanning everything that takes forever, I've got such a backlog you wouldn't believe). The packaging is beat to hell, but the disks aren't too worn (at least visually). Hopefully they're still functional.

[xelloss]

This just came in today. Hope to get it imaged and uploaded before the end of the week (the imaging is the easy part, it's scanning everything that takes forever, I've got such a backlog you wouldn't believe). The packaging is beat to hell, but the disks aren't too worn (at least visually). Hopefully they're still functional.

That's great! Fingers crossed...

[thunderbird32]

Well, I've tried to dump them as MFM sector images, and it says unknown for every sector. I've had good success on all 3.5" disks with the same settings, and was able to dump one 5.25" disk in the SCO Open Desktop set this way (though as that one disk was DS/DD 40-Track, I had to change that setting). However, the other disks in the SCO Open Desktop set have the same symptoms, so I guess I'm doing something wrong? I double checked and my drive is a 1.2MB one, so that's not it. Any ideas?

[mrpijey]

Do a raw stream dump and send it up and we can figure out the format.

[JustZisGuy]

Well, I've tried to dump them as MFM sector images, and it says unknown for every sector. I've had good success on all 3.5" disks with the same settings, and was able to dump one 5.25" disk in the SCO Open Desktop set this way (though as that one disk was DS/DD 40-Track, I had to change that setting). However, the other disks in the SCO Open Desktop set have the same symptoms, so I guess I'm doing something wrong? I double checked and my drive is a 1.2MB one, so that's not it. Any ideas?

Always start with a Kryoflux preservation stream dump. You can open the stream file in the HxC disk software tool to get a nice graphical overview of the contents: http://hxc2001.free.fr/floppy_drive_emu ... l#download
Given that this is a 1.2mb drive, you will need to manually make sure the density line is set appropriately. It is not always 100% possible to tell if a 5.25" disk is high or low density just by looking at it.
When using the Kryoflux software to decode an MFM disk or an existing preservation stream file made with a 1.2mb drive, you may need to add the parameter -v360. (The defaults assume 300 rpm) You can add this to the MFM profile's extra options text field in the GUI or as a DTC command line parameter. Check the manual to make sure you get the commands in the right order.

[thunderbird32]

That's fixed it! It was the RPM. It is mentioning that there is extra data in the header? Not sure if that means the disk has been modified.



The disk opens fine in WinImage though. I'm going to test in Win 2.1 tonight and see if it works fine, just for my own curiosity. Once I the packaging/manuals scanned I'll upload to the FTP.

[JustZisGuy]

I always have to explain this - the "H" simply means that a sector has been written to. Either by the end user, or in this case more likely the vendor if disk was just not professionally mastered.

The designers of the Kryoflux originally intended it only for use as a "preservation" tool. Therefore they treat user-modified sectors as an "error".

When you are arching a factory original title, this can be useful. It lets you know that the disk may not be pristine, and a better copy should be located. However, on user data disks, the "H" is meaningless.

Specifically what this detects is a small burst of random bits that occur at the beginning or end of an individual sector write operation. These do not occur on freshly formatted unwritten tracks, or on professionally mastered media where the entire track is written at once.

[thunderbird32]

Okay, so I tried it tonight and... it doesn't work. According to Kryoflux the disk has no bad sectors. However, for me the setup program always fails while unpacking the "exec.arc" file. Unfortunately, that's not the only bad file. I tried using the on disk pkunpak.exe to unpack some of the other files, and I get multiple bad files. I'll post it here in case anyone has any ideas how to make this work.


https://mega.nz/#!49kXSBTZ!xonUk18FKaef ... B_TLwke3i8


Also, one of the disks that contains the Windows runtime has one bad sector. I gave it multiple tries, and one bad sector is the best I could get (originally about 5 showed as bad). That's not super important, as the program should run fine under a normal Windows install.

Any ideas would be appreciated.

[Overdoze]

I tried it and have the same issue, multiple ARC archives are bad.

[JustZisGuy]

Ouch. That is bizarre. The Kryoflux dump appears to have been created perfectly, but the actual disk contents are wrong. A number of tracks are blank even though they should be used by files. The dump indicates that these tracks were never written to at all.

It is like they used diskcopy to create this disk but canceled at track 34.

At least the archive with the main AMI executable is in one piece, but the supporting files archives (starting in the middle of Dict.arc) contain blank sectors.

Those are the breaks, so to speak, of disk archival. Sometime disks don't contain what they say they do. And in this case, it looks like it was this way from day one.

[tarlabnor]

Ouch. That is bizarre. The Kryoflux dump appears to have been created perfectly, but the actual disk contents are wrong. A number of tracks are blank even though they should be used by files. The dump indicates that these tracks were never written to at all.

A simple question. What happens when you copy files from this disk without Kryoflux, using a simple dos utility diskcopy or a copy command ? Recently there was a case when attempts to dump a flippy SS/DD disk (without copy protection) using SuperCard Pro failed, because it's software (HxC) was unable to interpret properly format of this floppy disk. Yet a "standard" copy worked without any problem.

[JustZisGuy]

Recently there was a case when attempts to dump a flippy SS/DD disk (without copy protection) using SuperCard Pro failed, because it's software (HxC) was unable to interpret properly format of this floppy disk. Yet a "standard" copy worked without any problem.

That happens a lot with single sided or 8-sector low density formats (especially when 9 sectors or garbage on the second side are actually present), mainly because most disk tools don't take DOS 1.x eccentricities in to consideration.

But in this case the image seems to be a standard 1.2mb 5.25" high density floppy disk image. No matter how you view it, the data just isn't there.

[merlix]

I'm sorry if what I say is wrong, as I dont fully understand kroflux and maybe floppies in general. But are disks always at a constant rpm? My understanding was that they vary the speed going towards the outer edge, could you try dumping the tracks 35 on wards at a different rpm?

[JustZisGuy]

My understanding was that they vary the speed going towards the outer edge,

Only Apple Macintosh 400k/800k 3.5" drives, and a few other obscure drives use variable bitrates.

IBM PC drives spin at a constant rate (plus or minus a random minuscule fraction due to friction)

could you try dumping the tracks 35 on wards at a different rpm?

If there were a speed or bitrate mismatch, the sectors would fail to decode. In this case the sectors decoded perfectly and contained no user data.