Just implemented the lock signal to happen from the first memory I/O until the instruction finishes(e.g. during it's final cycles after the memory accesses, until the next instruction is going to start at the next cycle(the BIU is already finished doing it's work for the currently executing instruction at that point).

I've modified the DMA controller to (besides sampling the usual signals to determine if the CPU has released the bus for DMA) not start a DMA transfer(take control of the BUS) while the lock# signal is active, during it's S0 state. I assume the DMA is the only processor affected by the lock# signal on an old single core serializing x86 CPU system(like the 80386 and perhaps a 80486 handles I/O and instructions serially, without overlapping like a Pentium does)?

I'm quite sure the lock signal isn't connected to the dma and the 5160 datasheet doesn't appear to show that. It's not a problem though because the dmac asserts hold and doesn't do anything until the cpu asserts hlda which will prevent any bus conflict.

One little question: From when to when is the lock signal active? As I've currently implemented it, it starts during the first memory access by an instruction with a LOCK(0xF0) prefix(when accessing the first byte in memory, by the BIU, of the byte/word/dword value to be read/written(it doesn't differentiate between those, either one raises the LOCK# signal)). It ends(lowers the LOCK# signal) when the instruction has completed it's opcode handler and indicates it's finished(although this includes interrupts that fault during that time, which currently aren't handled through the BIU, but directly translate and access memory, bypassing the BIU timing handling). The instruction timing might not be finished yet, however. If the final instruction step completes from the current opcode handler and it returns some leftover timing for the instruction to the BIU to tick, said remaining ticks are made with the LOCK# signal disabled(as, to the EU, the instruction is finished(except still got some leftover time to tick)).

One little question then, about HLDA. Will the CPU(Actually the BIU?) assert HLDA in the middle of executing an instruction? So if a CMPXCHG instruction is running, or an INC/DEC etc.? The algorithm my BIU currently uses to do that(releasing the bus in my emulator), is just release the bus whenever it stalls the BIU(due to an instruction(e.g. jump) requesting it), T1 with nothing to prefetch(buffer is full) or transferring state from T4(80(1)8X)/T2(80286+) to T1.

Will the CPU(Actually the BIU?) assert HLDA in the middle of executing an instruction?

I don't know for sure but I highly doubt it. The cpu has to be halted first and AFAIK no x86 cpu will stop in the middle of an instruction for anything other than memory/io waits.

It seems so: http://www.ndr-nkc.de/download/datenbl/i8088.pdf

During T4 or T1 it says. Nothing is said about the instruction.

So, now the next question: what are the conditions for the CPU to assert HLDA, besides being at T4 or T1? I can't find it mentioned anywhere?