NathanA wrote: ↑Tue Apr 06, 2021 7:14 pm
My best guess about the story behind this 770Z image is that it wasn't a bit-for-bit rip of the media, but rather that whoever made it maybe copied all of the files off of it and then mastered a new ISO from that, or something. If you can link me to a URL to download a copy, I'd be interesting in dissecting it.
I have obtained a copy of this 770Z ISO from theterminator93, analyzed it, and think I can explain why it doesn't work.
It does indeed appear that my guess was correct: this ISO was remastered from scratch, rather than bit-for-bit ripped from the original media. (Argh. People need to learn how to use 'dd'.
) There's no smoking-gun here, just a lot of little tells that all add up.
This image is an ISO9660 filesystem
with Joliet extensions. The last bit is important. Joliet is an extension to the standard ISO9660 CD-ROM filesystem that Microsoft introduced with Windows 95, in order to add support for things like DBCS/Unicode and long file names to CDs. It in essence adds a second file/directory listing to the CD for every file on the disc, in a place where most ISO9660 implementations will not look (and so won't be bothered/confused by it, for backwards-compatibility with systems that don't know how to interpret Joliet discs).
(UDF didn't exist until after Win95 was released. Even so, the *NIX world already had Rock Ridge extensions, but MS gotta MS...
)
I don't know what software was used to master this image, but even though the disc contains no files with names longer than 8.3 characters, it's got a Joliet component to it, and the "correct" file names for each file are stored in there, while the names in the ISO9660 TOC are the weird ones without any file extensions (or where, if there was enough room within the first 8 characters, the extension was concatenated to the main file name with a '_' stuck in between, in place of the '.'). So "DFT.BAT" is called "DFT_BAT" in the ISO9660 listing, and "HKUSMA0.IMZ" turns into "HKUSMA08", etc. (so rules that are different than the normal VFAT long-to-short rules -- where you stuff a tilde '~' and a numeric suffix after the first 6 characters & before the extensions -- are being employed here by whatever CD mastering software was used).
Here's the thing: MSCDEX doesn't understand Joliet. There was no reason to ever update it to do so, since MS-DOS itself doesn't understand long file names. So if you mount this disc under Windows, you see the "right" names for each file. But under DOS, you see the wrong extension-less ones.
And of course, since IBM's image restore software is DOS-based and thus is dependent on MSCDEX to read the disc, and since it's going to be looking for *.IMZ files on this CD
and not be able to find any, it bombs out.
As a comparison, I downloaded one of two 770 images that I found on archive.org (in this case,
05L1802). The 770 image has no Joliet extension component, properly-named files within the ISO9660 TOC, and is even bootable right out of the gate. This 770Z image also uses the IBM P/N as the filesystem volume label, while it appears IBM used some other kind of identifier for the volume labels on their official media.
To be clear, the problem isn't that this image has Joliet extensions included. That in-and-of-itself isn't a problem. It's that the file names within the non-Joliet part are wrong (the mastering software renamed them, and only kept the correct names within the Joliet file listings, which are not accessible under DOS). But there really is no point to having Joliet extensions on this image in the first place, since there are no non-ASCII or longer-than-8-dot-3 file names anywhere on the disc. Clearly somebody copied these files off the original 770Z disc, and then when they created this image, they just accepted whatever default settings their ISO mastering software was configured to use, which apparently for some reason involved unnecessarily renaming files that didn't need to be renamed...
The one thing I still can't explain is why the floppy boot image appears to be short by 33 sectors (1,457,664 bytes instead of 1,474,560). However, the BOOTIMG.BIN file on the 770 image I compared this to is the exact same size, so I'm guessing that it's not actually missing any data and that's just how it is...?
Interestingly, 1457664 bytes is exactly how many bytes are free on a freshly-formatted FAT12 1.44MiB floppy diskette, and Microsoft explains the details behind this in
this old KB article of theirs: the first sector is the MBR, then 9 sectors each for the redundant FATs, and then 14 sectors for the root directory. That said, I can mount this image under Windows with ImDisk just fine, & you'd think all of that would necessarily need to be present for that to be possible, which leads me to conclude that a chunk of empty space at the end of the diskette image were simply chopped off / omitted for some reason. Also, it's clear that BOOTIMG.BIN is what's being used as the image for El Torito boot here (given the presence of BOOTIMG.CAT, the El Torito Boot Catalog)...and though perhaps the MBR itself might not need to exist in that context, certainly you'd think that at least one copy of the FAT + the root directory itself would need to! (I'm going to have to read up on El Torito again...)
theterminator93 wrote: ↑Mon Apr 05, 2021 8:40 pm
I do have a set for the 770, but I am not sure if it works. It's labeled 10L8564 and is 267 MB and I am not sure what OS it is for; it is bootable.
BTW, this (10L8564) is the same P/N that the second archive.org image I found bears...from the same repository as the 770X image that I pointed Edward at. I believe it is German-edition Win95. I'm going to guess/wager than when I unearth my own 770 restore discs, I'm going to find that their P/N matches the one I downloaded today for comparison (05L1802).
