The documentation is not entirely clear, so I would like to clarify the following:
1) While in Slave FIFO mode - doing Slave FIFO writes (external master outputs to FX2LP data bus inputs - SLWR asserted, IFCLK generated from external master, SLCS asserted = chip select enabled) can I use SLOE as an input?
SLOE is stated to affect the behavior when doing an SLRD. SLOE assertions tristate the database so FX2LP does not drive the bus when SLOE is de-asserted. However, if SLRD is deasserted - this will also "tristate" the data bus since either the part is not being asked to output values (SLRD and SLWR are deasserted) OR the part is being asked to handle a write (SLRD deasserted, SLWR asserted) in which case the buffers will be configured as inputs.
Does this mean that SLOE is a "don't care" for the case where SLCS# (active low) = 0, SLRD (active high) = 0, and SLWR (active high) = 1 or 0. We only use SLWR and never SLRD so sometimes there is data on the bus to read in which case SLWR will assert.
I want to make sure that SLOE does not also internally disconnect the data bus for inputs (during a slave fifo write).
Second part of the question is - that if SLOE is a "don't care" in the given scenario - can I read the state of SLOE to see if SLOE is asserted or not through firmware (8051)? I'm not sure if the port register for Port A will reflect the SLOE state in slave fifo write mode or if a read of SLOE will result in an invalid/unknown return (or always high or low - not reflecting SLOE).
The "trick" for SLOE I would like to gain an input since I never use SLRD which seems most tied to SLOE.
Your understanding of the SLOE functionality is correct. It does not affect the data bus for write operations (slwr asserted).
You cannot use sloe/slrd as a gpio and drive them in firmware since they will be mux'd internally to the slave fifo domain; and the gpio domain will not have control over these pins.