From Newsgroup: comp.sys.apple2

I tried running the "Apple II Audit" at https://github.com/zellyn/a2audit
on KEGS, and I have some questions.

I've found it not easy to debug when something's gone wrong--the error
message scrolls off the screen.

But it catches a "feature" of BURST which I put in intentionally--touching
the Language Card softswitches at $C081-$C08B turn on LC RAM writing after
just one access, and does not require the two accesses real hardware does.

This was an intentional choice. I figured there would be no software which would would touch one of the enable-write-to-LCRAM switches just once and expect RAM to not be writeable. But, there could be software which uses
a "trick" to access the switch twice (say, "INC $C081,X", which if X is 0,
will do two reads to $C081 and one write) and I didn't want to get that case wrong, since KEGS doesn't emulate these false reads yet.

But this a2audit thinks this is important, so if I'm to get this right,
I need more data.

What I'd like to know is the state of the LC RAM write enable after
all combinations of accesses to $C080-$C08F, followed by all other combinations of accesses. So this includes STA and LDA, and each address. I don't need
a full table, just enough to know what happens for each case (so, "Stores
do nothing" eliminates a lot of cases).

The IIgs documentation states pretty clearly that only READs to $C080-$C083
and $C088-$C08B affect the LC (Hardware Reference manual page 37, Table 3-1 indicates only Reads affect these locations). Is that correct? KEGS allows accesses to $C084-$C087 and $C08C-$C08F to also affect it. And KEGS allows writes to the registers to change state as well. This looks like KEGS
is wrong here. But, often the documentation is not really right--I'm sure reads work as documented, but perhaps writes work as well, but due to
the false read issue for some forms of stores, maybe they just don't
recommend using writes. I believe I tested this on my IIgs, but I don't remember how much testing I did, so I'm not sure if KEGS is right or wrong
on these points.

And, is the RAM write enable sticky even if the bank is changed? For instance:

LDA $C083
LDA $C083 ; Now bank2 is enabled for read/write
LDA $C08B ; Now, bank1 is enabled--but is it enabled for writes
; after a single access, since writes were already
; enebled?

And similarly, does LDA $C081, LDA $C081, LDA $C083 result in LCRAM writeable, even though ROM is switched from on to off?

Kent
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

The IIgs documentation states pretty clearly that only READs to $C080-$C083 and $C088-$C08B affect the LC (Hardware Reference manual page 37, Table 3-1 indicates only Reads affect these locations). Is that correct?

Only READs - yes; only those locations - unsure for the GS. The aliases that you note below are accepted on the IIe.
Yes, it requires two READs with no writes in between.
Any in-between write will reset the counter and require two more READS.
I think that I documented that part in the corresponding MAME code, but I don't remember now.

KEGS allows accesses to $C084-$C087 and $C08C-$C08F to also affect it.

That's correct for the IIe. I don't know if it's so on the IIGS.

And KEGS allows writes to the registers to change state as well. This looks like KEGS
is wrong here.

Yes, that's the wrong behaviour. Writes to $C080 etc will restore ROM banking, but writes to $C083, etc will not allow write-enabling.

And, is the RAM write enable sticky even if the bank is changed? For instance:

LDA $C083
LDA $C083 ; Now bank2 is enabled for read/write
LDA $C08B ; Now, bank1 is enabled--but is it enabled for writes
; after a single access, since writes were already
; enebled?

Yes it is. ProDOS relies on this behaviour, too, as far as I remember.

And similarly, does LDA $C081, LDA $C081, LDA $C083 result in LCRAM writeable,
even though ROM is switched from on to off?

Yes, that works as you think it does.
--- Synchronet 3.18b-Win32 NewsLink 1.113