Re: Cracking HomeWord

["Michael J. Mahon" <mjmahon@aol.com>]

Ivan X wrote:
> On 8/12/09 8:14 PM, in article
> 92580a2e-f352-436e-b51f-4f97bb79f935@c29g2000yqd.googlegroups.com, "N.N.
> Thayer" <nnthayer@hotmail.com> wrote:
>
> > I've posted the NIB images of both versions for anyone that's curious:
> >
> > http://www.drgw.net/~nnthayer/HW11.nib
> > http://www.drgw.net/~nnthayer/HW21.nib
>
> I've taken a look at the nib image of 2.1 and have gotten to the bottom of
> this. 
>
> Regarding the .NIB image file failing to work in II+ emulation under
> AppleWin because of the game port error: I have to conclude this is some
> anomaly specific to AppleWin, perhaps how it emulates the game port when
> using the II+ rom, because it works fine in II+ emulation under Virtual II.
>
> Regarding the .NIB image working but the .DSK image not working: During
> boot, HomeWord checks to ensure that the disk is volume number 004, and
> simply turns off the drive if it isn't. It also checks during program
> operation to ensure that the Homeword disk is in the drive when it needs to
> be (for example, when going to the disk utilities). A volume number can't be
> represented in a .DSK imagefile, because it is part of the sector header
> found in the raw nibble data. 99% of Apple II disks are volume 254, so that
> is what emulators report to the emulated hardware when .DSK images are
> loaded. So when you use Homeword as a .DSK image, the app sees the disk as
> volume 254, and dies.

As has been noted here before, the directory *does* contain the volume
number as a data field, but few (no?) emulators supply this number as
the emulated volume number (which it could do by simulating the low-
level formatting).  Other methods of communicating the desired volume
number to the emulator have also been discussed.

> The reason COPYA can copy the disk on a real II, and yet have the .DSK image
> file fail in an emulator, is that unlike some sector copiers, COPYA examines
> the volume number of the original disk and then INITs the target disk with
> the same volume number before copying. I was able to verify my theory by
> deleting line 250 (the INIT line), using the unbootable .DSK image as a
> source, and for the target using a .NIB image I had manually INITed to
> volume 4. The copy worked fine. I then repeated the process, but made the
> target volume 5; it wouldn't boot.
>
> The good news is that you have a functional .NIB image, and that should be
> all you need; that's (part of) why they exist, for nonstandard disks that
> .DSK can't handle.
>
> In theory, Homeword could be further "cracked" to bypass the volume check
> during startup and during program operation, and then it should work as a
> .DSK, though I'm not sure it would be worth the effort since you've got the
> .NIB already. It also would lose its ability to ensure that the Homeword
> disk is in or out of the drive when it needs to be.

Actually, it would be good to continue the crack to eliminate the
volume check.  DSK images are much more generally useful than NIB
images.

-michael

NadaNet 3.0 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."