[OFFER+HELP NEEDED] Unused dBase III Plus 1.1 (with problems)
So, here's an interesting problem. What do you do when you have a virgin copy of dBase III with one of the disks in the media set being dead. The version on winworld is serialized and ID'ed, but mine appears to be virgin (although I'm not 100% sure). The winworld version also appears it was hexedited after the fact to remove the serial number and identification code from displaying in dBase. There may also be other changes. My disk is writable, but I don't see any obvious signs of modification, but I'm not an expert here.
I used my SuperCard Pro to dump the disks, so these are from a raw copy I made from the originals; here's what happens when you try to install. I know @SomeGuy was looking at Aston-Tate's ID process, but as far as I know, this is the first copy that's cropped up without being pre-personalized.
I was able to serialize a copy of the disks, and confirmed that it does indeed work. The serialization process is run on both the System_1 and Administration_1 disks as far as I can tell, but I haven't had much time to play w/ it.
The problem is my Admin 2 disk appears entirely dead. It's just getting a null read no matter what I try. I've heard of some steps like using soap to try and clean the cookie to get the disk to read, but I also have no reason to suspect that this isn't identical to the disks that are on winworld.
I'm happy to give these disk images uploaded "as is", but I'd prefer to get the set. I'm also not sure if these are really virgin so I kinda want some help before I post them for inclusion on the site. I did get good reads of the other disks, but the media is def. degrading; it took multiple tries to get error free dumps of the other six disks. Some advice on how best to handle this is welcome.
I used my SuperCard Pro to dump the disks, so these are from a raw copy I made from the originals; here's what happens when you try to install. I know @SomeGuy was looking at Aston-Tate's ID process, but as far as I know, this is the first copy that's cropped up without being pre-personalized.
I was able to serialize a copy of the disks, and confirmed that it does indeed work. The serialization process is run on both the System_1 and Administration_1 disks as far as I can tell, but I haven't had much time to play w/ it.
The problem is my Admin 2 disk appears entirely dead. It's just getting a null read no matter what I try. I've heard of some steps like using soap to try and clean the cookie to get the disk to read, but I also have no reason to suspect that this isn't identical to the disks that are on winworld.
I'm happy to give these disk images uploaded "as is", but I'd prefer to get the set. I'm also not sure if these are really virgin so I kinda want some help before I post them for inclusion on the site. I did get good reads of the other disks, but the media is def. degrading; it took multiple tries to get error free dumps of the other six disks. Some advice on how best to handle this is welcome.
Comments
And here's dBase III Plus showing that it has indeed been IDed correctly
Honestly, thinking about this, I'm wondering if what I'm looking at is a manfactoring error, and somehow the Admin 2 disk was shipped unformatted. I'll have to check to see if the Administration disk was personalized. This is kinda strange however you look at it.
EDIT: just as a point of clarification, if someone wants to look at the disk images, I'll DM them a link. I just don't want to publish them "as is" as an incomplete set and risk creating confusion.
At a glance, it looks like the disk may have been reformatted for some other system. If it wasn't still shrink-wrapped, then this is likely.
First of all, when plotting with HxC, just use the "dummy disk" option. This shows ALL tracks. It looks like their 5.25" 48TPI option incorrectly assumes the image was dumped on a 96tpi drive and omits half of the tracks. (I wish they would put the controls back at the bottom of the screen, at the side it forces the graphics plot to be so much smaller)
Still, something looks screwpot. Notice the second red line at an odd angle? This show where something started and stopped writing. It is index aligned, but nowhere near the normal index. That is weird. That makes no sense here. Second, just looking at the vague blue flux plot, it sort of looks like 15-sectors. AKA high density, but I can't be sure. Whatever is written, HxC does not seem to recognize it as MFM or FM. The lack of any random red marks suggest that it may technically be reading OK.
So, try this:
First just check the head in your disk drive, perhaps run a cleaning disk through it.
Then sanity check by reading in a known good disk.
Visually check the surface of the disk for any damage or scratches. Use good light, and a magnifying glass if needed. Gently turn the disk cookie by the hub to inspect the entire surface front and back.
Listen for any odd scraping sounds, and note if the disk cookie does not turn freely.
In the drive, make sure the disk spins properly. Unfortunately, during the dumping process, the SCP does not note the rotational speed.
Redump, double checking that your SCP settings are appropriate for the drive. I'm guessing you are using a 360k drive.
Since I have a suspicion this disk may have been reformatted with a high density drive, you might also try using a high density 5.25" drive to provide an additional dump. Make sure all 80 tracks are read in, and try specifying both "high" and "low" density.
If this low density disk was reformatted high density in a 1.2mb drive, then the results probably will be not entirely readable.
If the dumps still look nonsensical, go ahead and send me all three dump variations (360k drive, 1.2mb drive low density, 1.2mb drive high density), and I will look and see if I can spot what the deal is.
* the dBase III Plus version on the site is ID.EXE and appears hexedited to remove personal info
* The System_I and Administration_I disks I have appear to have never been personalized
* All disks aside from Admin 2 were readable, although I did have to make a few retries at times to get sectors to dump.
I've tried to dump Administration 2 with scp_dump, the official Windows program, my 360k Teac drive, and the 1.2M HD Teac drive to no avail.
It's just that one disk that refuses to read; I've tested known good disks in both the DD and HD drives I have, here's what the HxC dump looks like for System_1, dumped with the 360k DD drive. I've had to manually limit the scp_dump command to 80 tracks for DD dumps, otherwise it will try to seek to track 163 and head bank from 81->163.
I should note that almost all the disks I've ever dumped with SCP have that red line in roughly that position and not in line with the index hole. It might be a problem with the Linux Disk-Utilities package. (I did try using the Windows SCP tool, but I find it didn't make a difference)
I'll get the SCP dumps uploaded and sent to you. These are all the dumps I took with the 360k DD drive, and HxC reports healthy dumps. All disks beside the Admin 2 one are readble.
I did try the Administration 2 disk in HD drive and once again got essentially line noise, but I don't know what I did with the file.
Are you on IRC or willing to join either the Winworld discord or my own person one? I could try things in real time and screen share to figure out what's going on. I may have to redump some of the other things if there's a more general problem. I'll send you a DM link to get the first set of SCP files.
Recently I added another set that was unused except for the tutorial disk, but I couldn't figure out if the tutorial disk from the first set was untouched or not, so I added it as an "alternate".
So I'll compare your set and perhaps finally combine them.
I don't normally do real time chat. Too many things going on at once. Besides, most discussion about this type of thing should be public so others can benefit from it.
Thanks.
I'm just sorta thinking that this might be legitimately unformatted though ...
Looking closer, it does sort of look like low density MFM, but with enough bits missing that everything looks like gibberish.
Whatever this is, it is not the administration disk. but it is not completely blank. Could be partially degaussed, or written with an electrically damaged drive. I'm just curious about this, but I probably should not worry about it that much.
That does remind me, when I dumped that last set, there were a couple of tracks that seemed like nothing would decode. But when I put it in an actual computer with a real floppy disk controller, it somehow worked fine. That pattern looked completely different, but if you have a real IBM PC or clone, you might try that just for shits.
I'm debating if I want to write a known good image back to the physical disk, but I'm happy I did my bit for software preservation. I'll put the SCP images up publicly after I sleep.
How'd you read the MFM stuff? I've tried working with hxc and I struggle to even use the tool. I understand the theory of MFM encoding, but hxc seems difficult to use to do this sorta stuff w/.
For more detailed analysis, I usually use the tools bundled with the PCE emulator. These are entirely command line but offers much more fine-grained analysis and manipulation.
The PCE tools have the ability to decode a flux image to a hexadecimal text file that contains all FM, MFM, or GCR data on a single track. This is very handy for analyzing copy protections, manipulating non-standard protected sectors, and repairing bit-level data errors.
For example with the PCE tools, I can see, edit, and restore the data placed in the gap area after a sector by the protection scheme used on Harvard Presentation Graphics and similar titles.
But sometimes it is nice to have a graphical data plot, as sometimes patterns just jump out.
For example, on that HxC plotted graph of your admin 2 disk, that second red line pops out suggesting that each track stopped being written after about 60% of the way through.
After thinking about it, that is exactly what would happen if someone tried to write a 9-sector low density track while the floppy controller was in high density write mode while the disk is in a 360RPM 1.2mb drive. That also explains why the data is evenly garbled, and un-decodeable, as low density drives simply can not read high density signals.
So, I think if you read that disk in with a high density drive in high density mode, it might reveal what the previous user was smoking. Of course, low density disks can not store high density data, so chances are only the first few tracks will be even vaguely readable at all.
It is up to you if you want to re-format that disk and restore its content. I see nothing wrong with that. That is part of the reason we make disk images available here, so users can restore borked up disks.
But that is not what happened here, the disk was not really "blank", just in the wrong density drive. I guess he never re dumped with high density, but it is unimportant because it is obviously not the data we are looking for.
Incidentally, the downloads have been updated with the verified good disk dumps.