I have a code that is supposed to work on a II plus or a IIe, and I want to use the soft switch at $C00E to make sure the alternate character set is off (required for flashing text).
It seems this should be OK, but then I noticed in the Apple IIe reference manual it says "in the original Apple II, memory locations from $C000 to $C01F were used only for the keyboard data and strobe functions." This way this is phrased got me worried.
Does anyone know if the Apple II plus keyboard input (or anything else) could get tripped up by a code that addresses location $C00E (specifically, POKE -16370,0)?
"Built-In I/O
The Apple's built-in I/O functions are mapped into 128 memory locations beginning at $C000. On the Apple board, a 74LS138 at location F13 called the I/O selector decodes these 128 special addresses and enables the various functions.
The 74LS138 is enabled by another '138 at location H12 whenever the Apple's address bus contains an address between $C000 and $C0FF. The I/O selector divides this 256-byte range into eight sixteen-byte ranges, ignoring the range $C080 through $C0FF. Each output line of the '138 becomes active (low) when its associated 16-byte range is being referenced.
The "0" line from the I/O selector gates the data from the keyboard connector into the RAM data multiplexer.
..."
"Keyboard Connector
The data from the Apple's keyboard goes directly to the RAM data multiplexers and latches, the two 74LS257s at locations B6 and B7. The STROBE line on the keyboard connector sets a 74LS74 flip-flop at location B10. When the I/O selector activates its "0" line, the data which is on the seven inputs on the keyboard connector, and the state of the strobe flip-flop, are multiplexed onto the Apple's data bus."
from Apple ][ Reference Manual
Discussion: The data written by the processor onto the data bus goes through a multiplexer shared with the keyboard data. This means that when the I/O selector decodes the keyboard range, it imposes the data from the keyboard instead of from the CPU onto the bus. But the processor just did a write cycle, so it doesn't latch that back in. The net result is that no visible state was changed: it acts as a no-op.
Writing (or reading) from $C010 - $C01F resets the strobe flag, which could cause the RDKEY routine to drop input. $C00E will not have that effect.
Don't worry. You can POKE $C00E all you want on the Apple II.
The data from the keyboard only drives the data bus on a READ. So there is no bus contention.
I should certainly hope not. There should not be any way for software to cause contention, shoot-through, or latchup. I understood the qustion as being about the keyboard port state and input routines.
Well your earlier response said : "The data written by the processor onto the data bus goes through a multiplexer shared with the keyboard data. This means that when the I/O selector decodes the keyboard range, it imposes the data from the keyboard instead of from the CPU onto the bus. But the processor just did a write cycle, so it doesn't latch that back in. The net result is that no visible state was changed: it acts as a no-op."
If you were refering to the data multiplexors at B6/B7, then it's just the opposite. These chips select between the RAM and Keyboard data and determine what will be presented TO the bus (and thus the CPU). If these multiplexors were not disabled during a write instruction, there would be bus contention.
And indeed, there's lots of ways that software can cause this. Like writing to ROM at C8xx.
I think our misunderstanding may have come when I said "the bus" twice while referring to two different things.
The processor writes to DB<7:0>_latched. This is one input to the multiplexer, and strobe_ff+keyboard<6:0> is the other. The multiplexer's output is on DB<7:0>. Both the input and the output are the data bus, but they are not the same wires.
Still not sure what you are trying to say. The processor reads and writes directly (through a buffer) to the "DATA BUS." Are you referring to this (from Sather):
Screen Shot 2021-09-17 at 10.02.13 PM.png
Thanks for the above comments.
The sentence from the //e manual following the one I quoted in the original post: "In the Apple IIe, these locations are used the same way, but only when you *read* to get data and *write* to clear the strobe." (emphasis carried over from the reference).
This suggests to me that on the Apple II or II plus, either a read or a write in the range $C000 through $C00F will activate line 0 of the I/O selector. That is, only the //e distinguishes between read and write in this context.
So I'm guessing that this POKE I was worried about will indeed activate line 0 on a II plus (but not on a //e).
As I understood the comments everyone agrees this amounts to a no-op at any rate, and therefore nothing to worry about. If this is wrong please let me know.
I apologize: I was wrong about the operation of the bus (should serve me right for posting without sleep). What I did was rely on the RFI addendum to the Apple II Reference Manual by Chris Espinosa. It shows H10 as an empty box: I assumed it was a latch but it's a bidirectional transceiver. I also missed that B6/B7 have an /Enable pin as well as /Select, so they are tri-stated whenever /RAM SEL is inactive.
I should have said that since /RAM SEL is false during write cycles, the keyboard mux won't drive the data bus. The byte that the CPU writes to $C000 is just cast into the void, because nothing on the board is selected to receive it. It is available to peripheral cards if they wanted to use it (but most won't). It is still the case that it is effectively a no-op.
You also seem to be correct that the ROMs are selected to drive the data bus whenever the address bus is in the ROM range, regardless of the state of R/W. This seems like a silly oversight to me, but I guess there may be a deeper reason for it. Does the R/W signal have insufficient strength to drive the spare chip selects on the ROMs?
I think the missing context in "in the original Apple II, memory locations from $C000 to $C01F were used only for the keyboard data and strobe functions." is that those functions are in separate 16-byte ranges. The range assigned to /KBD, $C00x, can only be used to read the keyboard port and writing it does not do anything.