Re: Ultima 1 (1986 reissue version) woes

[Hot Rod <hotrod.apple2@gmail.com>]

On Wednesday, July 25, 2012 1:20:40 PM UTC-5, BLuRry wrote:
> On Wednesday, July 25, 2012 12:15:35 PM UTC-5, Hot Rod wrote:
> > On Wednesday, July 25, 2012 11:30:58 AM UTC-5, BLuRry wrote:
> > > Either a failing nibble count or a difference in timing that results in a skewed sector placement within a track.  I suppose emulators can't handle that too well since they have a very fixed view of how the disk should work.
> > > 
> > 
> > I kinda doubt it would be a nibble count, since this would be for creating a player disk.  On a real Apple, are the resulting player disks copyable? (Would think so, to allow them to be backed up.)
> > 
> > It could be trying to write out a volume number, and not getting it read back.  Might be timing, but other tools are able to write disks in the emulator.
> > 
> > Just have to look at the code...
> 
> I got a bizzare error from my emulator when it was trying to denibblize the data back to a DSK format while saving the track -- it was scanning for a marker but was unable to find it -- and I keep my logic a little loose so it was a bit of a surprise to see that.  Strange thing is that the U1Player.dsk image from asimov works fine so you wouldn't expect it to need a NIB disk image.
> 
> It is very very odd.  :-D
> 
> -B

So it looks like the routine in question is at $AB63, which is called from $A8A2.  When it returns, it seems to want the value in $D4 to be between #$0E and #$1B, but in AppleWin, it comes back as #$1C, even though the call to $AB63 returns with the carry bit clear(and the play disk seems to be created OK).

When the check fails, it loads the accumulator with #$03 and returns (which then displays the drive speed error message).

By NOPing $A8C8 (EA EA EA), it *seems* to work; it at least continues into game play, and if I eject the player disk, it complains about putting it back in to make it happy (and continue play).

But I'm not an Ultima player by any means, so take it FWIW.

I haven't checked where that code is on the disk image, so you may have to find it, or just change it in the emulator during run time.

Now, I haven't dug into what the actual count is that it's storing in $D4, that is failing the check.  The routine at $AB63 seems to format tracks and sectors, but bounces around in a big loop, and I got tired of following it.  There may be a better fix, by determining what is being counted.  Might be something that real hardware knows to limit, whereas an emulator just keeps going.

Anyway, this might at least be a way to let it run in the emulator.

]HR