Issue in bank 1 writing about apple2js HOT 3 CLOSED

Thanks for the bug report! There's definitely a bug because MMU._prewrite is never actually read.

From Understanding the Apple IIe by Jim Sather pp. 5-23 to 5-24:

Writing to high RAM is enabled when the HRAMWRT' soft switch is reset. The controlling MPU program must set the PRE-WRITE soft switch before it can reset HRAMWRT'. PRE-WRITE is set by odd read access in the *C08X range. It is reset by even read access or any write access in the $C08X range. HRAMWRT' is reset by odd read access in the $C08X range when PRE-WRITE is set. It is set by even access in the $C08X range. Any other type of access causes HRAMWRT' to hold its current state.
...
PRE-WRITE and WRITE can be thought of as a write counter which counts odd read accesses in the $C08X range. The counter is set to zero by even or write access in the $C08X range. If the write counter reaches the count of 2, writing to high RAM becomes enabled. From that point, writing will stay enabled until an even access is made in the $C08X range. This means there is a feature of RAM card control not documented by Apple: write access to an odd address in the $C08X range controls HRAMRD without affecting the state of HRAMWRT'.

Let's break that down into more manageable chunks:

PRE-WRITE

PRE-WRITE is set by odd read access in the *C08X range. It is reset by even read access or any write access in the $C08X range.

In the emulator, PRE-WRITE is MMU._prewrite. So, MMU._prewrite should be set when writeSwitch && readMode and reset when (!writeSwitch && readMode) || !readMode. The suggested code captures this intent with:

        if (writeSwitch) { // 0xC081, 0xC083
            if (readMode) {
                if (this._prewrite) {
                    ...
                    this._prewrite = false;  // <-- incorrect ???
		} else {
                    this._prewrite = true;
                }
            } else {
                this._prewrite = false;
            }

            ...
        } else { // 0xC080, 0xC082
            ...
            this._prewrite = false;
            ...
        }

The one thing that I'm not sure about is the reset on read when PRE-WRITE is already set (commented line above). This appears to be an error if Sather is correct. According to figure 5.13a on p. 5-30, PRE-WRITE does not depend on anything but A0 and R/W', which supports not resetting PRE-WRITE when it's enabled. If you can find other evidence, one way or the other, I would be interested.

HRAMWRT'

HRAMWRT' is reset by odd read access in the $C08X range when PRE-WRITE is set. It is set by even access in the $C08X range. Any other type of access causes HRAMWRT' to hold its current state.

In the emulator, HRAMWRT' is MMU._writebsr, but the emulator uses regular logic. So, MMU._writebsr should be set when writeSwitch && readMode && MMU._prewrite. It should be reset when !writeSwitch. The suggested code captures this intent with:

        if (writeSwitch) { // 0xC081, 0xC083
            if (readMode) {
                if (this._prewrite) {
	            this._writebsr = true;
                    ...
                }
            ...
        } else { // 0xC080, 0xC082
           this._writebsr = false;
           ...
        }

This seems like it works fine.

I'll try to make a change tonight to fix this bug otherwise I'm sure that @whscullin will get to it before long.

from apple2js.

Probably need to verify that the fix do not cause any regression using the a2audit test from https://github.com/zellyn/a2audit

from apple2js.

Reopening the issue as only realized it is fixed in forked version at iflan/apple2js

from apple2js.