Apple II interpreter crashes on unenhanced IIe

[danielgaskell]

The Apple II interpreter fails to load on unenhanced Apple IIe:

Symptoms

On cold boot, disk read stops at track 5 and does not resume. Subsequent warm boots will typically get as far as "Insert story disk and press a key." (for single-disk systems - this prompt is skipped on dual-disk systems), but once Å-code starts running text output is periodically corrupted and the game will eventually crash (often before reaching the first prompt). The corruption appears random and is different on every boot, sometimes yielding rather eldritch results:

Only unenhanced Apple IIe seems to be affected; emulated Apple II, Apple II+, and enhanced Apple IIe seem to work correctly. (Guess which machine I have, LOL.)

Reproducing

Game: Murder in Nineveh (release 11)

Hardware: Both the cold-boot freeze and the warm-boot corruption were consistently observed on real hardware (unenhanced NTSC Apple IIe Revision B). This machine passes all diagnostics, and the behavior remained consistent across a variety of hardware configurations: all cards (serial, Z80, etc.); only 80col + Disk II cards; only Disk II card (no 80col/auxmem); swapping the Disk II card with another known-good card; and swapping real Disk II drive for FloppyEmu.

Emulation: AppleWin reproduces the cold-boot freeze but not the warm-boot corruption (see AppleWin on Linux for a Linux port of this emulator). Neither issue manifests on Apple2TS.

Next steps

Since the RWTS is well-tested (and other software using ProRWTS2 works on this machine), my next best guess is that something in the auxmem/caching system is erroneously assuming Enhanced behavior (or is fragile to uninitialized RAM values on real hardware).

[danielgaskell]

(Same behavior now confirmed on a separate unenhanced PAL Apple IIe Revision B.)

[dstelzer]

Oh dear! Tagging in @sehugg .

[sehugg]

Initial tests with izapple2 seem to indicate it doesn't like 80-column mode on unenhanced //e, but that doesn't mean there's more than one thing going on. IIRC the C64 version assumed RAM was zeroed out so there may be uninitialized memory somewhere still.

If I force 40-column mode (and uppercase, b/c inverse characters work different) it seems to work on the emulator.

[sehugg]

There were/are a few problems. First, the auxtest routine got unwired at some point, probably when rolling my own MACHID detect routine. So it was assumed that IIe always had 128KB. Oops. But now the routine tests for 80 column page buffer and the full 64KB of aux memory separately.

But there is still a problem with 80 column mode on unenhanced IIe that shows up on izapple2. So I'm going to leave it forced to 40 columns for now (you can also force 40 columns by pressing '4' on boot)

There were also a few changes required to support inverse lowercase on 40 columns, since enhanced and unenhanced models have different character sets :^P

If you wouldn't mind, I've attached a disk image to try.

Cloak-of-Darkness-auxtest.dsk.zip

[danielgaskell]

Thanks! This image no longer has the "stop on track 5" problem, but still has the corruption problem. (FWIW, both of my unenhanced IIe's have a full 64KB auxmem - on different varieties of 80col cards - but not the Enhanced chipsets.)

[sehugg]

Okay I did find at least two more actual bugs which affect unenhanced IIe.

The engine calls $C300 to initialize the 80-column card, but on the unenhanced IIe it needs the monitor ROM switched in for some reason. That was probably the cold-boot problem.

But also the unenhanced 80-column ROM is a little different. It uses the zero page address $1F for stuff. Guess what the engine used it for? The "auxram" zero page variable which turns on and off aux RAM swapping.

I am confident the attached disk image will have different bugs, or fewer bugs (hopefully)

Cloak-of-Darkness-unenh-fix.dsk.zip

[danielgaskell]

Well, different bugs anyway! 😂

I think the cold-boot problem is fixed, but I'm still getting corruption in the game text/code. FWIW the text corruption seems to follow text-source transitions, like abbreviations ("and") or strings (the Dialog compiler version string), but it's random on every boot and the code is also being affected enough to trigger crashes.

[sehugg]

Bummer. You said the diagnostics passed all 64K of aux RAM?

[danielgaskell]

Yes, all diagnostics pass (and other programs that use aux RAM seem fine).

[sehugg]

Does it still have problems if you press '4' during boot to force 40-column mode?

[danielgaskell]

Yes, same issue.