Re: Cracking HomeWord

["N.N. Thayer" <nnthayer@hotmail.com>]

On Aug 13, 9:07 am, Ivan X <ivan...@yahoo.com> wrote:

> 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.

The weird thing is that it works fine in my ][+ which has a joystick
attached (through a 9-pin adapter to the game port).  Perhaps the
error message is a vestige of, say, version 1.0, or a beta version,
and is being brought to the surface by an AppleWin bug.  Strange!

> 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.

That matches what I was observing before I applied any cracks.  When I
attempted a physical-disk copy of the uncracked version of 2.1., the
drive ran briefly and then just quit (locking the system in the
process, requiring a power-cycle to reboot - nice).

> 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.

Interesting!  I've imaged hundreds of disks, and these are the first
I've run across with that specific issue - I guess the reason it
wasn't addressed in any of the old Computist cracks was that, back
then, physical disk copies were all you had to worry about.

> 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 guess Copy II Plus does this too, since physical-disk copies worked
fine with that program.

> 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.

The only reason I'm after a DSK instead of a NIB is that, as far as
I'm aware, there's no reliable method for transferring NIB images to
physical 5.25" disks, so anyone wanting to run HomeWord on a real II
without original disks would be SOL.

Thank you so much for your help.