WOZ: Fishies doesn't boot reliably

[tomcw]

Using AppleWin 1.29.11.0, it only boots ~1 in 10 times, and even when it boots, it never gets past the intro screen. (After the short tune, the fish goes back and forth a few more times, then it should boot to the aquarium mode. Use F(eed), T(ouch) and SPACE to interact!)

Running in stepping mode, then often it'll hit a BRK or undefined opcode. Sometimes it'll stop at the Applesoft prompt (but in HIRES mode, so text to show). RETURN causes it to retry booting.

I disabled the Wasteland fix, but that didn't seem to make any difference.

NB. The image must be write enabled, otherwise it'll show an error msg "REMOVE WRITE PROTECT TAB"... but the disk is never written to (neither .woz or .dsk).

Both attached images from apple2infinitum.slack.com on 16/4/2020.

John Morris' image: Fishies.zip

Other emulators with this .woz:

• Works with Christopher Mosher's Epple-II.
• Antoine: "OpenEmulator stops at the wrong write protect tab"
  • OpenEmulator does not support writing to woz files... so presumably .woz images are r/o.
• J.Morris: "I think Virtual ][ is barfing on the protection track."
• MAME 0.220: just black screen.
  • But from the debugger, Debug->New Memory Window, and pick "Apple II video/:a2video/m_graphics", then change this soft-switch from 1 to 0 to show the TEXT screen... it's showing "Apple //e"
• m8: just black screen.
  • But from the web debugger, set TEXT mode, it breaks to the monitor at $9F02 (4 retries)

Antoine Vignau's "pseudo crack": Fishies - Disk 1, Side A cracked pfew.zip

I've restored all the deleted files. None are useful apart from the last file from the catalog which generates the 4*4 nibbles on T3 (loaded and executed at $8EE)

The deleted ROTATED WRITER PACKAGE is the key

Why? Because it writes the needed code/data onto T3 which is later decyphered by the program. So, if one understands which data is being recorded, then you will have to write it directly onto the sectors w/o encoding

[tomcw]

In DataLatchReadWriteWOZ(), with significantBitCells = 100, then it seems to boot more often.
Increasing to significantBitCells = floppy.m_bitCount doesn't seem to help further.

Also after the intro boots, then I've never got it to start the "game"... it either reloads the intro, or crashes/hangs.

[tomcw]

The Slack discussion centred on the "~30% chance of a 1 bit" when the head window has a run of 4 zero-bits. Epple-II used 50%... when this was reduced to 33% then it too would fail (1 in 7 times).

I tried AppleWin: upping (from 30%) to 50% chance of a 1 bit... and it works every time.
NB. Sometimes from the intro it'll reload the intro instead of the main aquarium/game.

[tomcw]

After the intro, it hits $BC56. (Full routine from $BC56-BCF6)
On Slack, Antoine says:

That code at $BC56 reads T3 (4*4nibbles) and decyphers it. There is a nice (and useful) waste of time once it has got its first valid nibble.

[tomcw]

On Slack, Antoine identified this code as "The faulty code" :

b92f		lda c08c,x
		bpl b92f
		cmp #$de
		beq b99e / exitOK
		pha
		pla
		lda c08c,x
b93d		cmp #8
		bcc b99e / exitOK
		nop
exitNG
b942		sec
		rts
		
		:

		lda c08c,x
b999:		cmp #8
		bcs b942 / exitNG
		nop
exitOK
b99e		clc
		rts

[tomcw]

Only do "50% chance of 1 bit" if fishiesFix == true (otherwise stick to 30% chance):

bool fishiesFix = (addr == 0xc0ec && (pc == 0xb93d || pc == 0xb999));

• works mostly
• occasional BRK into monitor at 9F04
• occasional BRK into monitor at A4D4

bool fishiesFix = (addr == 0xc0ec && pc == 0xb93d);

• T0-S9: BRK into monitor at A4D4
• T0-S9: BRK into monitor at A399
• T0-S9: BRK into monitor at A399
• T0-S9: BRK into monitor at A4D4

bool fishiesFix = (addr == 0xc0ec && pc == 0xb999);

• boot to intro, then keeps reloading intro... eventually
  • I/O ERROR
  • BREAK IN 40
• boot to intro, then keeps reloading intro... eventually
  • blank screen
  • RETURN reload intro
• boot to intro, then keeps reloading intro... eventually
  • T0-S9: BRK into monitor at AE6C
• T0-S9: BRK into monitor at 9F04 (NB. didn't boot to intro)
• boot to intro, then keeps reloading intro... eventually
  • T18-S15 / blank screen... RETURN continues...
  • T14-S11 / blank screen... RETURN continues...
  • T0-S9: BRK into monitor at A4D3

[tomcw]

For a normal nibblized sector:

• address & data field epilogues are: DE AA EB

Just looking at track $00: Fishies-T00.txt

• all addr epilogues are: AF(2) or AF(+)
• all data epilogues are: ED(2) or ED(+)
  • where (2) is 2 zero bits and (+) is >9 zero bits

In "The faulty code" above, it's checking for a regular "DE" nibble (at the end of the field).

• if it finds "DE" then exitOK (this is just the regular nibblized sector case)
• if it has (2) zero bits, this will delay the next 1-bit, resulting in a latch value < 0x08 (exitOK)
  • if it's a copy, then these zero bits won't be there, and the latch will be >= 0x08 (exitNG)
• but if it has (+) zero bits, then the zeros will continue to hold the latch with the previous nibble
  • upping from 30% to 50% chance of a 1 bit means that there's more chance of a 1, so more chance that the previous nibble will be dumped
  • NB. definition of nibble is b7 set, so >= 0x08... so exitNG

[mr-stivo]

It's interesting that the person who posted the a2r on Slack said the original disk boots on his machine. Something is amiss.

I found your explanation of the problem very helpful. Thanks for the details and the quick workaround.

[tomcw]

I'm at a bit of a loss with this woz image. Here are a few random thoughts...

Just because an original Fishies disk boots on real hardware doesn't tell us the whole story, eg:

• how many epilogue failures are occurring on this real setup?
  • perhaps measurable by just timing the time-to-intro & time-to-game; or using more sophisticated h/w to trace out the track/phase positions
  • repeat this boot/timing 100 times to get some statistically significant data
• how clean is the real disk drive's read head? (how can you even measure this?!)
• with AppleWin, sometimes it'll boot to the intro, then on attempting to load the "game" it will just reboot the intro (and repeat before eventually loading the "game"). Does this also happen on a real setup?

Someone on Slack also mentioned a ramp (eg. gradually going from 30% to 50%), perhaps there's some physical reason (eg. temperature) that could influence this?

It would be interesting to better reverse engineer the protection to understand if any particular sector(s) are more key to the whole protection system that others. EG. maybe the woz image is just a little bit too ideal for a few key sectors... so maybe changing a few run of 4 zero bits to 0010 (eg. flipping a single bit) is enough to "fix" the image.